You Decoded the Base64 and Got Gibberish. Here Is What You Actually Have

You have a string. It looks like Base64. You decode it and get this:

�4�z�!�...

The usual conclusion is that it was not Base64 after all, and the next hour goes into trying every other decoder in turn.

It almost certainly was Base64. It decoded correctly. The problem is that Base64 is not an encoding of text — it is an encoding of bytes, and those bytes were never text to begin with.

Count the characters first

Before trying anything else, count. The length of the encoded string tells you the length of the decoded bytes, and the byte length is often enough to identify the thing outright.

Base64 turns every 3 bytes into 4 characters, padding the end with = so the length is always a multiple of 4.

Encoded length	Padding	Decoded bytes	Almost certainly
24	==	16	MD5, or a UUID
28	=	20	SHA-1
44	=	32	SHA-256
88	==	64	SHA-512

If your string is 28 characters ending in a single =, you have twenty bytes of hash. No decoder will ever turn it into text, because it was never text. A hash is a one-way fingerprint, and there is nothing on the other side to recover.

To do the arithmetic yourself: take the encoded length, subtract the padding characters, multiply by 3, divide by 4.

What the padding is for

The = at the end confuses a lot of people, and it is worth thirty seconds.

Base64 works in blocks of 3 input bytes. If the input does not divide evenly by 3, the last block is short, and the padding says by how much. One = means the last block held 2 bytes. Two == means it held 1. No padding means it divided evenly.

That is the whole meaning. The padding carries no data, which is why some systems strip it — JWTs do, for one. If a decoder complains about invalid length on a string that looks fine, try adding = until the length is a multiple of 4.

When it is not a hash

If the length does not match a hash, look at the first few decoded bytes. Most binary formats announce themselves.

Starts with	It is
PK	A zip file, or anything zip-based — docx, xlsx, jar
‰PNG	A PNG image
ÿØÿ	A JPEG
%PDF	A PDF
\x1f\x8b	Gzip
{ or [	JSON that just needs its own decode step

Two PK bytes at the front and you are holding a compressed archive that somebody base64'd to move it through a text field. That is extremely common in API payloads and config files.

When it is genuinely not Base64

A few tells, before you go further:

Length is not a multiple of 4 and adding padding does not fix it. Base64 output is always a multiple of 4.

It contains characters outside the alphabet. Standard Base64 uses A-Z a-z 0-9 + / and =. If you see - and _ instead of + and /, that is base64url, used in JWTs and URLs. Same data, two substituted characters. Most decoders handle both, but a strict one will refuse.

It is all uppercase hex. A1B2C3D4 is hexadecimal, not Base64. Hex uses only 0-9 A-F and produces twice as many characters as bytes.

It has % sequences. That is URL encoding. %20 is a space. Decode that first, and you may find Base64 underneath.

The nested case

Encodings stack, and stacked encodings are where most of the confusion actually comes from.

A URL-encoded Base64 string of gzipped JSON is a completely normal thing to find in a tracking parameter. You decode the URL encoding, get Base64. Decode the Base64, get \x1f\x8b. Decompress that, get JSON.

Each step looks like failure until you check what you are holding. The rule that saves time: after every decode, look at the first two bytes and the length before deciding it went wrong.

Do it without guessing the format first

Most decoders ask you to pick the method before you paste, which is backwards — what encoding this is happens to be the question you are trying to answer.

The string decoder runs the input through Base64, Base32, hex, URL encoding, HTML entities and JWT parsing, and shows you which ones produce something. When the answer is "Base64 worked and gave you twenty bytes of binary", that is not a failure. That is the answer: you are holding a SHA-1, and there is nothing inside it to find.