A transaction id, sixty four hex characters

A transaction identifier is sixty four hexadecimal characters in an unbroken run, written in lower case by convention.

The shape

Length: 64 characters, exactly
Alphabet: hexadecimal: the digits 0 to 9 and the letters a to f
Case: lower by convention; upper case is the same value and is still valid
Separators: none: no spaces, no hyphens, no colons, no grouping of any kind
Prefix: none; a leading 0x is a display habit borrowed from elsewhere
Line handling: one run, though a narrow column may wrap it across two visual lines

0123456789abcdef0123456789abcdef
0123456789abcdef0123456789abcdef

One string of 64 characters, shown as two rows of 32. It is 0123456789abcdef repeated four times, which is the counting up placeholder this site uses wherever an alphabet has no letters to spell with.

A crowded shape

Sixty four hexadecimal characters is one of the most heavily reused shapes in computing, and this reference alone documents two things that wear it. A SHA-256 file hash has precisely the same length, the same alphabet and the same casing convention; it is described at a file hash. Block identifiers wear it too, and so do any number of internal database keys.

The two are indistinguishable by shape alone. Not difficult to tell apart, not usually distinguishable with practice: indistinguishable. There is no marker inside a transaction identifier that a file hash lacks, no reserved range, no positional giveaway. Anyone who claims to recognise which is which from the characters is reading the label above the field, not the string.

That label, and the context in which the string arrived, are the only things that separate them, and both sit outside the string where no format check can reach. A hash quoted as an identifier and an identifier quoted as a hash will both pass every test on this card.

How to check it by eye

Sixteen, thirty two, sixty four

Sweep for any letter past f. A single g through z means the string is not hexadecimal and belongs to some other alphabet on the alphabets.
Count in two halves of thirty two, or four quarters of sixteen. Halving is easier than counting a single run of sixty four.
Look for a leading 0x, a trailing full stop, or a colon. Strip them mentally, then count again, because the count you did first included them.
Check the case is uniform. A mixture is still the same value, but it tells you the string was handled by something in transit.

What a wrong shape means

Sixty three or sixty five characters is the usual result of a selection that missed by one at an edge, and it is far more common than any other fault in this shape. Recount before concluding anything, since counting sixty four characters by eye goes wrong easily.

A letter beyond f means the alphabet is wrong, which usually means the string is something else entirely: a base58 address, a base64 fragment, an opaque token. Mixed case together with letters past f is a strong hint of base58 or base64 rather than a damaged identifier.

A mixture of upper and lower case, with everything else correct, is harmless as a value and informative as a signal. Something along the way applied a case transformation, so the string did not travel untouched. That matters less here than it would for a bech32 address, where a mixture is invalid outright.

As with the rest of this family, a wrong shape describes the journey. It does not describe an intention.

What a correct shape does not prove

This card has the widest gap on the site between what the shape confirms and what a reader tends to assume from it. Sixty four clean hexadecimal characters leave all of the following untouched.

That the string is a transaction identifier at all. A file hash is the same shape, and so are several other things.
That any transaction exists. Sixty four hexadecimal characters can be typed by anybody in a few seconds, and the result will pass every test here.
That it relates to your order, your amount or your address. The identifier carries no reference to any of them.
That anything has confirmed, or when. This site consults no chain and prints no confirmation figures.
That the identifier was not copied from somewhere else entirely and presented as yours.

What this card is not

The identical shape worn by file hashes, and what it is used for there, is at a file hash. Addresses are not hexadecimal and are covered from the older Bitcoin form onwards. Shorter hexadecimal strings that describe a key, rather than a transaction, are a short key id and a long key id.

Questions people send about this shape

Can a reader tell a transaction id from a file hash by looking?

No. Both are sixty four hexadecimal characters, lower case by convention, with no separators and no prefix. Nothing inside either string marks which it is. The only separation comes from the label on the field and the context it arrived in, and both of those are claims made by whoever built the page rather than properties of the string.

Does 0x belong on the front of one?

It does not. A leading 0x is a convention from programming languages for marking a hexadecimal literal, and it turns up when a value passes through a tool that adds it. The identifier is the sixty four characters after it. If you count with the prefix included you will get sixty six and wrongly conclude the string is malformed.

Is upper case wrong?

Not wrong, just unconventional. Hexadecimal is case insensitive as a value, so an upper case rendering represents the same thing. Its presence does tell you something worth noting: the string passed through a step that transformed it, so it did not arrive exactly as it was published.

A transaction id