Raw transaction hex versus a transaction ID
A transaction ID is a 64-character hexadecimal identifier. Raw transaction hex is the serialized transaction itself, including its input references, outputs, scripts and any included witness. A transaction ID alone is not enough for this tool. Get the raw data from your own wallet, a trusted node or a source you trust; this decoder does not retrieve it.
What the decoder can show
It reads the transaction structure with the open-source bitcoinjs-lib parser, computes identifiers and shows exact output values in satoshis and BTC. Input and output indices start at zero. Recognised output templates include legacy P2PKH/P2SH, native SegWit P2WPKH/P2WSH, Taproot, public-key and OP_RETURN scripts. Unclassified scripts stay visible as hex.
Why are bytes and virtual bytes different?
SegWit discounts witness data in transaction weight. This tool reports weight = stripped bytes × 3 + total bytes, then virtual size = ceil(weight ÷ 4). The fee planner uses virtual bytes. Copy the decoded vsize and enter a hypothetical or independently obtained sat/vB rate to explore a fee scenario.
Can raw hex tell me the fee?
Ordinary transaction fees are the sum of spent previous-output values minus the sum of new outputs. The input outpoints in raw hex point to those earlier values; they do not include the values themselves. The decoder therefore shows fee and fee rate as unavailable. An output total is neither the fee nor a reliable “amount sent”, because change and other outputs can be included. Coinbase rewards are a separate case.
TXID and witness transaction hash
TXID excludes witness serialization. The displayed WTXID hashes the full serialized bytes; it can differ when witness is included. For coinbase entries, this is the serialization hash: the separate witness-commitment calculation in BIP141 uses a zero placeholder for coinbase. Both identifiers are displayed in the usual reversed-hash byte order.
Does the address format prove the network?
No network identifier is carried in these raw transaction bytes. The mainnet, testnet/signet and regtest choice controls how recognised output scripts are encoded as addresses. It cannot identify where the transaction was created or accepted. A recognised script template also does not verify its keys, signatures or spendability.
Why does a successful decode not prove payment?
Parsing checks structure, not the full consensus rules or chain state. This tool does not verify signatures, look up previous outputs, test mempool acceptance or count confirmations. Current witness data may be incomplete if you pasted a stripped serialization. Confirm receipt and status in the actual receiving wallet or trusted node.
Sequence signals are not a fee-bump verdict
The explicit BIP125 signal checks whether a non-coinbase input has a sequence below 0xfffffffe. Replacement can also depend on ancestry, node policy and other conditions. A missing explicit signal does not establish that a transaction cannot be replaced. Locktime fields likewise need sequence and chain context to interpret their effect.
Privacy and supported input
Paste transaction hex only, never wallet secrets. The decoder accepts spaces and line breaks, rejects trailing or noncanonical serialization, and limits transaction size to 100 KB and 2,000 inputs/outputs. PSBTs and other formats are outside its scope. Entered hex and decoded values are kept in page memory only; edits invalidate the old result, and Clear removes the input and displayed data.
Related: Bitcoin fee planner, BTC/satoshi converter, latest Bitcoin blocks and transfer-status guide.
Primary sources: bitcoinjs-lib, Bitcoin Core decoder fields, BIP141 witness and weight definitions and BIP125 explicit signalling. Pinned component licences and build provenance.