Every time you send Bitcoin, your wallet quietly assembles a raw transaction behind the scenes. Most beginners never see it. It's a string of hexadecimal characters that looks like noise, but it carries every instruction the network needs to move funds from one address to another. Understanding what a Bitcoin raw transaction actually is gives you a clearer picture of how the network works at its most fundamental level.
What a raw transaction actually is
A raw transaction is Bitcoin in its serialised, machine-readable form. It isn't a receipt or a confirmation. It's the unsigned (or freshly signed) data structure that your wallet constructs before broadcasting a payment to the peer-to-peer network. Think of it as the envelope, the letter, and the sender's signature all compressed into one continuous block of data.
The encoding is hexadecimal, which means each byte of data is represented as two characters: numbers 0 through 9 and letters A through F. A simple transaction might produce a string 200 to 400 characters long. A more complex one, involving multiple inputs or outputs, can stretch considerably further.
Bitcoin's network doesn't process plain English instructions. It processes these serialised structures, validates them against the rules of the protocol, and either accepts or rejects them. That process sits at the heart of how Bitcoin transactions work.
The components packed inside
A raw transaction has a fixed structure with distinct fields. Each field serves a specific function, and the order is strict.
- Version number: A 4-byte field telling nodes which transaction format rules apply. Most standard transactions use version 1 or version 2.
- Inputs: Each input references a previous unspent output (UTxO) that the sender controls. It includes the transaction ID of that prior output, the output index, and a scriptSig (the unlocking script proving ownership).
- Outputs: Each output specifies an amount in satoshis and a scriptPubKey, which is the locking script that defines who can spend those funds next.
- Locktime: A 4-byte field that can prevent the transaction from being mined before a certain block height or Unix timestamp.
SegWit transactions add a witness field between the inputs and locktime sections. This field holds the digital signature data separately from the main transaction body, which is what reduces the transaction's effective weight and lowers fees. If you use a SegWit address, your wallet generates a raw transaction in this extended format automatically.
Why the raw format matters for beginners
Most wallets hide all of this. You enter an address, type an amount, and press send. The raw transaction is constructed, signed, and broadcast without you seeing any of it. That convenience is fine for everyday use, but it creates a gap in understanding that can lead to costly mistakes.
For instance, the fee you pay isn't a percentage of the amount sent. It's calculated from the size of the raw transaction in bytes, multiplied by the fee rate you set (or your wallet sets for you). A transaction with three inputs and two outputs will be physically larger in bytes than one with a single input, so it costs more to broadcast even if the amount sent is identical. This is directly connected to how Bitcoin UTxOs affect your wallet and why fragmented holdings can lead to unexpectedly high fees.
Knowing that a raw transaction exists also clarifies what "broadcasting" means. Your wallet doesn't send money to a server. It publishes a raw transaction to the peer-to-peer network, where nodes validate it and miners eventually include it in a block. The transaction is public from the moment it's broadcast, visible to anyone monitoring the mempool.
Constructing and signing a raw transaction manually
Advanced users and developers sometimes build raw transactions by hand, using tools like Bitcoin Core's bitcoin-cli command-line interface. The process has four steps: gather the UTxOs to spend, construct the raw transaction hex, sign it with the relevant private key, and broadcast it.
Signing is the critical step. An unsigned raw transaction is just a plan. The network won't accept it until a valid digital signature proves the sender controls the private key associated with the funds being spent. The signature is generated using the Schnorr or ECDSA algorithm, depending on the address type, and it gets embedded into the scriptSig or witness field before broadcast.
This manual process is rarely necessary for ordinary holders, but it's invaluable in specific situations: recovering funds from a custom script, constructing a partially signed Bitcoin transaction (PSBT) for multisig approval, or debugging a stuck payment. It's also how Bitcoin fee bumping works under the hood, where a new raw transaction replaces an unconfirmed one with a higher fee attached.
Raw transactions and privacy
Because a raw transaction is public once broadcast, every input, output, and amount is visible on the blockchain permanently. The transaction ID (txid) is derived by double-hashing the raw transaction data with SHA-256, producing the unique identifier you see in a block explorer.
One practical consequence: if your wallet constructs a raw transaction with a change output sent back to a reused address, anyone reading the blockchain can connect your transaction history across multiple payments. Wallets that generate a new change address for each transaction, using a hierarchical deterministic structure, solve this by making the raw transaction harder to link to a single identity.
What you don't need to do with this knowledge
You don't need to read raw transactions directly, decode hexadecimal strings, or construct transactions by hand to use Bitcoin safely and confidently. A well-designed wallet handles all of it. But knowing that the raw transaction exists, what it contains, and how it moves through the network makes you a more informed holder. It's the difference between pressing a button and understanding what the button actually does.
When something goes wrong, that understanding is exactly what helps you diagnose it. A transaction stuck in the mempool, an unexpectedly high fee, a change address you don't recognise: each of these traces back to the raw transaction structure, and knowing the structure tells you where to look.

