How to Preview a Base64 Image in JSON

You open a JSON file and one field is a 40,000-character wall of gibberish: "avatar": "iVBORw0KGgoAAAANSUhEUg...". That's a base64-encoded image — a real picture stuffed into a text string. Most viewers show you the noise; ours shows you the picture, rendered inline as a thumbnail.

A practical guide · Updated 29 May 2026

What a base64 image in JSON actually is

JSON has no binary type, so to ship a picture inside a payload — an avatar, a scanned receipt, a QR code — an API encodes the raw bytes as base64: a text-safe run of letters, digits, +, and /. You'll see it as a bare blob or a full data URI with its own MIME type:

{
  "id": 42,
  "label": "Profile photo",
  "avatar": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...",
  "thumb":  "iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAAC..."
}

To a human reading raw JSON, both fields are useless noise. You can't tell if avatar is a logo, a headshot, or a corrupted byte salad — you just trust the key name and move on.

Why an inline preview matters

Here's the part no other JSON viewer we've found bothers to do: it renders the image. Instead of copying a 40 KB string out into a separate base64 decoder in another tab, you see the actual picture next to its key. A tedious detour becomes a glance — you can tell instantly whether an avatar's bytes are a valid PNG or an accidental error page, or scan a whole response of generated thumbnails like a contact sheet.

Preview one in three steps

Open the viewer →

What the viewer recognises as an image

Detection is deliberately conservative so plain text is never mistaken for a picture. A string renders as an image when it is:

• A data URI — anything starting with data:image/ (png, jpeg, gif, webp, svg+xml) followed by ;base64, and a payload. The unambiguous case.
• A bare base64 blob with a known magic header — long, valid base64 beginning with a recognisable signature (PNG starts with iVBORw0KGgo, JPEG with /9j/) is decoded even without the data: prefix.

Everything else stays as text: a UUID, a JWT, or a sentence of prose fails the signature and length tests, so it's never drawn as a broken thumbnail.

Base64 images inside tables

Images shine in table view. When your JSON is an array of objects — products each with a photo, users each with an avatar — the viewer lays them out as rows, and the image cell shows a thumbnail per row:

[
  { "sku": "A-100", "name": "Mug",    "photo": "data:image/png;base64,iVBORw0KGgo..." },
  { "sku": "A-101", "name": "Bottle", "photo": "data:image/jpeg;base64,/9j/4AAQ..." }
]

You get a scannable grid — SKU, name, and an actual picture per row instead of two columns of base64 sludge. For how rows and columns are chosen, see the companion guide on how to view JSON as a table.

Is the image uploaded anywhere?

No. The viewer is a single HTML file with no backend and no upload endpoint. Your JSON — base64 image bytes included — is decoded and drawn by your browser's own JavaScript engine, and the editor is masked from session-recording analytics, so nothing you paste is ever transmitted or captured. That matters when the embedded images are scanned documents or ID photos. The note on whether a no-upload JSON viewer is safe walks through why.

Quick FAQ

Does it work without the data:image prefix?

Yes for common formats. A bare PNG or JPEG blob is detected by its magic header and decoded. If a format has no recognisable signature and no data: prefix, it stays as text — there's no reliable way to know it's an image.

Will a giant base64 image slow the page down?

Decoding is cheap and only visible thumbnails are drawn. In tables, virtual scrolling renders only the rows on screen, so thousands of embedded pictures stay smooth — and the original base64 is still there to copy when you expand a field.

Open the viewer and try it →