Bitcoin transaction size and fee calculator

Count your inputs and outputs by address type, enter a fee rate, and get the transaction's weight, virtual size in vbytes and fee, worked out byte by byte from the SegWit rules. A comparison shows what the same payment would take with legacy, SegWit or Taproot addresses.

Updated 2026-10-20 · 5 min read

Free, and runs entirely in your browser: nothing you type is sent anywhere.

How to use the calculator

1. Inputs are the coins (UTXOs) you spend. Count them by the type of address they were received on: a wallet that pays from three bc1q addresses has three P2WPKH inputs. For multisig, set how many signatures are required (m) out of how many keys (n).
2. Outputs are the payments plus any change back to you. A typical payment has two: the recipient and your change.
3. Fee rate is in satoshis per virtual byte (sat/vB). Take the current rate from your wallet or a mempool explorer; this page makes no network requests.

The result shows the virtual size the fee is charged on, the weight, the raw size in bytes and the fee. The table at the bottom breaks the total down part by part, and the settings stay in the page address so you can share a calculation.

Weight, vbytes and bytes

Since SegWit, transaction size has three measures. BIP 141 defines weight as base size × 3 + total size, where base size leaves out the witness data. Put simply, each non-witness byte counts 4 weight units (WU) and each witness byte counts 1 WU. Virtual size is the weight divided by 4, rounded up to a whole vbyte, and it is what fee rates apply to. The raw size is the number of bytes actually sent over the network. Blocks are limited to 4,000,000 WU (block weight), and Bitcoin Core doesn't relay a single transaction above 400,000 WU by default.

So fee = virtual size × fee rate. For a legacy transaction all three measures line up (weight is 4 × bytes); for SegWit and Taproot, signatures sit in the cheaper witness.

How the calculator counts bytes

Transaction overhead. 4 bytes of version, 4 of locktime, and a count of inputs and of outputs (1 byte each below 253, 3 bytes up to 65,535). If any input has witness data, the transaction is serialized with a 2-byte marker and flag (BIP 144). They count as witness: 2 WU, or 0.5 vB. Every input in such a transaction then carries a witness field, and legacy inputs get an empty one of 1 byte (0.25 vB), which the calculator adds.

Inputs. Each input has a 36-byte outpoint (txid and output number), a script length and scriptSig, and a 4-byte sequence, all at 4 WU per byte. Witness items (signatures, public keys, scripts) each have a length prefix and count 1 WU per byte.

Signatures. ECDSA signatures are DER-encoded and, with the sighash byte, take up to 72 bytes when the signature's R value has its top bit set, or 71 bytes otherwise. Some wallets, Bitcoin Core among them, grind for a low R so their signatures are always 71 bytes. The calculator assumes 72 bytes by default (worst case) and lets you choose 71; each ECDSA signature changes the size by 1 byte, or 0.25 vB in a witness. Taproot key-path spends use a 64-byte Schnorr signature (BIP 340), 65 bytes only if a non-default sighash is used (BIP 341).

Multisig inputs use a CHECKMULTISIG script: OP_m, n public keys of 33 bytes, OP_n and OP_CHECKMULTISIG, which is 3 + 34n bytes. The spending data starts with an empty dummy item that BIP 147 requires, followed by m signatures. A P2SH redeem script is limited to 520 bytes, which allows up to 15 keys. (In the 2-of-3 P2SH row, the 71-byte figure drops by 4 vB, not 2: the scriptSig falls below 253 bytes, so its length prefix shrinks from 3 bytes to 1.)

Each output is an 8-byte amount, a 1-byte script length and the script. Outputs never have witness data.

Example: a typical SegWit payment

One P2WPKH input paying two P2WPKH outputs (a payment and change):

• Overhead: 10 bytes × 4 = 40 WU, plus 2 WU for marker and flag = 42 WU
• Input: 41 bytes × 4 + 108 witness bytes = 272 WU
• Outputs: 2 × 31 bytes × 4 = 248 WU
• Total: 562 WU, so 140.5 vB, rounded up to 141 vB. At 10 sat/vB the fee is 1,410 sats.

The same payment from and to legacy P2PKH addresses is 226 vB. As a check on the method, with 71-byte signatures selected the calculator reproduces the signed P2SH-P2WPKH example transaction in BIP 143 exactly: 251 bytes and 677 WU.

How much SegWit and Taproot save

Moving signatures into the witness is where the savings come from: a P2WPKH input is 68 vB against 148 vB for P2PKH. The SegWit guide explains why the discount exists.

Taproot is subtler. A P2TR key-path input (57.5 vB) is smaller than a P2WPKH input (68 vB), but a P2TR output (43 vB) is larger than a P2WPKH output (31 vB), because it holds a 32-byte key instead of a 20-byte hash. A 1-input, 2-output Taproot payment is 154 vB against 141 vB for P2WPKH, while a 3-input, 1-output consolidation is 226 vB against 246 vB. Taproot's biggest savings are for multisig and complex scripts: with an aggregated key such as MuSig2 (BIP 327), a multisig spend looks like a single 57.5 vB key-path spend. Because that depends on how the wallet is built, the comparison chart keeps multisig inputs as P2WSH in its Taproot row. See BIP 141 vs BIP 341 for more.

Limits of the estimate

• Real ECDSA signatures can occasionally be a byte or two shorter than 71 bytes, so a wallet's figure may be slightly lower.
• Taproot script-path spends, timelocked scripts and other custom scripts aren't covered: their size depends on the script and, for Taproot, on the script tree.
• Fees are rounded up to a whole sat. To raise the fee of a transaction already sent, see replace-by-fee and child pays for parent, which is what keyless anchor outputs like P2A are for.