Bitcoin Script
disassembler.

Opcodes

120+

full table, incl. Taproot

Templates

P2PKH → OP_RETURN

Network

None

decodes locally

Auth

None

no wallet, no signup

/31—SCRIPT DISASSEMBLER

ready

awaiting input

▸ /notes

Pushes carry the payload.

Opcodes are the plumbing; the keys, hashes, and data all arrive via push operations. Reading a script is mostly reading what gets pushed and which check consumes it.

Templates rule the chain.

Nodes only relay standard output shapes, which is why almost every script matches one of a handful of patterns. What those patterns demand from a spender is the subject of the locking-scripts explainer.

Data outputs burn bytes, not coins.

OP_RETURN outputs are provably unspendable carriers for up to 80 bytes of arbitrary data. They still pay for their bytes like any other output, at the going sat/vB rate.

▸ /faq

Where do I find script hex to decode?

Block explorers show each output's scriptPubKey as hex, and raw transactions contain it directly. Paste that hex here; the disassembler splits it into opcodes and matches it against the standard templates.

What are the OP_PUSHBYTES opcodes?

Bytes 0x01 to 0x4b are not named operations: each one means "push this many following bytes onto the stack". Longer pushes use OP_PUSHDATA1/2/4 with an explicit length. Almost everything interesting in a script (keys, hashes, data) arrives via pushes.

Why do most scripts look identical?

Because virtually all outputs use a handful of templates: P2PKH, P2SH, P2WPKH, P2WSH, P2TR, and OP_RETURN. Wallets refuse to send to nonstandard scripts, so the interesting variety lives inside P2SH redeem scripts and witness scripts, which you can also paste here.

Does this validate the script?

It disassembles and pattern-matches; it does not execute. A syntactically valid script can still be unspendable (bad keys, impossible conditions). For semantics, the unlock-conditions explainer covers what each standard template actually requires.

Bitcoin Scriptdisassembler.