BitcoinDatabase.com

Query the chain · Transaction decoder

Bitcoin transaction decoder for raw hex, inputs and outputs

A Bitcoin transaction decoder turns an opaque string of hex into something you can actually read: the version, every input with its previous txid and output index, every output with its value in satoshis, the script type, the decoded address, the witness data and the locktime. Bitcoin Core does this with decoderawtransaction, but that means running a full node. BitcoinDatabase decodes the same structure over a REST call, so you paste a raw transaction hex and get clean JSON back.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

You can also decode by txid: give us any confirmed transaction hash and we return the fully decoded transaction from the indexed chain, complete with input addresses and amounts that a raw decode alone cannot resolve. Use it in the API for an app, in SQL for a batch, or in a dashboard for a one-off check. Informational on-chain data only, not financial advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Transaction decoder

Hex to readable JSON

Pass a raw transaction hex and get back the version, inputs, outputs, script types, decoded addresses, amounts in satoshis, witness data and locktime, the same fields decoderawtransaction returns, without running a node.

Decode by txid too

Give us a confirmed transaction hash and we resolve the full picture from the indexed chain, including the input addresses and spent amounts that a bare raw decode cannot show because they live in prior transactions.

Every script type parsed

Legacy P2PKH, P2SH, wrapped and native SegWit and Taproot outputs are all parsed to their address form and script type, so you read who was paid without decoding scriptPubKey by hand.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Decode raw transaction hex to structured JSON
  • Decode any confirmed transaction by txid
  • Resolve input addresses and spent amounts
  • Read script types and decoded output addresses
  • Batch-decode transactions via API or SQL
GET /v1/address/{addr} query result
200 · JSON
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Transaction decoder

Send the raw transaction hex to the decode endpoint and it returns readable JSON: version, inputs, outputs, amounts in satoshis, script types, decoded addresses, witness data and locktime. It is the decoderawtransaction result over REST, so you never run Bitcoin Core to parse a transaction.
Yes. Pass a confirmed transaction hash and BitcoinDatabase returns the fully decoded transaction from the indexed chain, including input addresses and spent amounts that a raw hex decode cannot resolve on its own. This is informational on-chain data, not advice.
Because they are not in the transaction. An input references a previous output by txid and index, and the address lives in that earlier output, not in the spending transaction. To resolve input addresses and amounts you have to look up every previous output, which means an index. Decoding hex alone gives you structure; decoding against an indexed chain gives you the addresses and values too.
They tell you how each output can be spent. In a full census we ran on block 963,670, outputs broke down as 56.91 percent v0_p2wpkh, 18.90 percent op_return, 12.54 percent v1_p2tr, 4.60 percent p2pkh, 4.26 percent p2sh and 2.26 percent v0_p2wsh. Note that nearly a fifth of outputs were OP_RETURN and carry no spendable value at all, so any code that sums outputs without filtering them will overstate what actually moved.
By length, not by prefix. Both start with bc1q. A native SegWit v0 key hash address is 42 characters and a script hash address is 62 characters. Truncating either one breaks the bech32 checksum, and most explorers answer a truncated bech32 address with HTTP 400 rather than a not-found, which looks like a dead address when it is really a malformed one.
It is the first byte of the decoded base58check payload and it says what kind of address you have: 0x00 for P2PKH, which renders as a leading 1, and 0x05 for P2SH, which renders as a leading 3. Other chains reuse the same encoding with different version bytes, so a string can be a valid base58check address and still not be a Bitcoin one. Checking the version byte rather than the leading character is how you catch that.
Change. Most Bitcoin transactions send the remainder of their inputs back to an address the sender controls, so raw output totals overstate real payment volume. We measured this on two blocks: in block 963,402, 79.45 percent of output value was change and raw volume overstated real transfers by 4.87 times; in block 962,547 the same method gave 17.03 times. Subtract change before you quote a volume number, and never reuse a single adjustment factor.
Yes, if you have the raw hex. Structure, outputs, script types and locktime all decode without the transaction ever being mined. What you cannot get is confirmation status, block height or timestamp, and input amounts still need the previous outputs resolved from an index. Mempool transactions can also be replaced, so treat a decode of an unconfirmed transaction as a snapshot of an intent, not a settled fact.
Weight counts witness bytes at one quarter the cost of non-witness bytes, vsize is weight divided by four, and fee rates are quoted in satoshis per vbyte against vsize rather than raw size. If you compute a fee rate against raw byte size you will understate it on any SegWit transaction. It is the most common arithmetic error we see in code that parses transactions.
Not for decoding, and running a node solves a different problem than most teams think. A node gives you consensus validation and privacy; it does not give you an address index, so it cannot answer questions that start with an address unless you build one. Our cost breakdown for running a node puts a production setup in the region of 390 to 430 dollars a month on AWS, which is worth it for validation and rarely worth it purely to parse transactions.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics