Image to Base64

What it does

Drop an image (JPG, PNG, WebP, GIF, SVG, or any other format your browser can decode) and get back a base64-encoded data URL you can paste straight into HTML, CSS, JSON payloads, email signatures, Markdown documents, or anywhere else that accepts an inline image.

A data URL looks like data:image/png;base64,iVBORw0KGgo… — the prefix tells the browser the MIME type, the rest is the file's bytes encoded in base64. Inlining is useful when you need the image to ship as part of a single document (no separate image request, no CORS, no relative-path bugs) — the classic uses are email signatures (where remote images often get blocked), CSS background images for tiny icons (saves an HTTP request), HTML email templates, and pasting screenshots into JSON or Slack-style chat payloads where attachments aren't supported.

The encoding adds about 33% to file size — a 30 KB PNG becomes a ~40 KB data URL. That's the tradeoff: portability for size. For images larger than ~50 KB, prefer hosting them and linking instead — large data URLs make HTML files slow to parse and break copy/paste in many contexts.

How to use it

1. Drag-drop your image into the upload area or click to browse.
2. The data URL appears immediately — there's no convert button.
3. Click Copy to put the full data URL on your clipboard. The MIME prefix (data:image/png;base64,) is included so you can paste it directly into <img src="..."> or background-image: url(...).
4. Use Copy as <img> tag for HTML, Copy as CSS background-image for stylesheets, or Copy raw to grab just the encoded bytes (useful for JSON / email API payloads).
5. If your image is over 100 KB, the tool warns you — at that size, hosting a real file is almost always better than inlining.

When to use this tool

• Email signatures — most email clients block remote image requests, so an inlined logo always renders.
• HTML emails / newsletters — same reason: data URLs survive when relative paths and remote hosts don't.
• Tiny icons in CSS (under 5 KB) — saves an HTTP request, faster than hitting a CDN.
• Pasting screenshots into JSON or chat APIs that don't accept binary attachments.
• Self-contained HTML demos / proof-of-concepts where you don't want a separate image folder.

When not to use it

• Large images (>100 KB) — the +33% size tax balloons quickly. Host the file and link instead.
• Any image used on multiple pages — a hosted file gets cached by the browser; a data URL re-downloads with every page.
• Production websites at scale — bloating HTML with megabytes of base64 makes initial render slow.
• Images that benefit from compression / CDN — Cloudinary or imgix will deliver a smaller, more cache-friendly file than a data URL.