How to check the real format of a Base64 image on a Mac
You can do this with B64 by pasting the payload in. Here is where the declared and actual types are shown, and what to do when they differ.
A data URI says what it is: data:image/png;base64,…. That declaration is written by whatever produced the URI, and whatever produced the URI may have been guessing — from a file extension, from a form field, from a default that was never revisited.
B64 reads the bytes instead.
Check a payload
Paste it into Decode
Press ⌘2 and paste — raw Base64, a data URI, or a payload inside HTML, CSS or Markdown.
Read the format beside the picture
That is the actual format, determined from the bytes.
Open the Inspector for both values
⌥⌘I shows declared — what the data URI claimed — next to actual. When they disagree, a short note appears beside the result.
When a declaration and the bytes disagree, B64 trusts the bytes and says so. Saving the image writes it with the extension its bytes deserve, because any other choice produces a file that misleads every program that opens it.
How formats are recognised
Every image format begins with a distinctive signature — a magic number — and because Base64 is deterministic, that signature always produces the same opening characters.
| Base64 starts with | The file is |
|---|---|
iVBORw0KGgo | PNG |
/9j/ | JPEG |
R0lGODlh or R0lGODdh | GIF |
JVBERi0 | |
UklGR | WebP |
SUkq or TU0A | TIFF |
Qk | BMP |
PHN2Zy or PD94bW | SVG |
AAAAIGZ0eXBoZWlj | HEIC |
You never need to memorise these — the app reads them for you — but they are useful when you are looking at a payload in a log and want a guess before you paste it anywhere.
Why the two disagree so often
- Somebody typed the prefix by hand.
image/pngis the one people write from memory. - A pipeline defaulted. An uploader that labels everything
image/jpegregardless of what arrived. - The source file was renamed rather than converted. The extension changed; the bytes did not.
- A converter did not update the prefix. The image was converted; the label was left behind.
Why it matters
A mislabelled payload is a bug that only shows up sometimes. Browsers sniff the bytes and render the picture anyway, so it works on your machine. Stricter consumers — a mail client, a validator, an API that checks the declared type against an allow-list — reject it. The failure appears at the far end, long after the cause.
Catching it while you have the payload in front of you is the cheapest possible moment.
Fixing it
The fix is at the source, not in the payload. Save the decoded image with Save… — it is written with the correct extension — then encode it again in Encode, where the data URI prefix is written from the actual bytes. The new URI is labelled correctly.
Troubleshooting
There is no declared type at all
A raw Base64 string or a data:;base64, URI declares nothing. The bytes decide, and the Inspector shows only the actual type.
The format is one I did not expect
Then the payload is not the file you thought it was. Check where it came from — a surprise format usually means a surprise source.
It decodes but reports no format
The bytes are valid Base64 of something that is not an image or a PDF.
Frequently asked questions
How does B64 know what format a payload really is?
From the bytes. Every image format starts with a distinctive signature, which the app reads rather than trusting the label on a data URI.
What happens when the data URI says one thing and the bytes say another?
B64 shows a note, trusts the bytes, and saves the image with the extension its bytes deserve.
Why does a mislabelled data URI matter if browsers render it anyway?
Because stricter consumers do not. A mail client, a validator or an API that checks the declared type will reject it, and the failure appears far from the cause.
How do I fix a mislabelled payload?
Save the decoded image, then encode it again — the new data URI is written from the actual bytes.