Image to Base64

BASE64 DEVELOPER IMAGE PRIVATE
Share:
By Checked against sources by , Founder & Architect, RECATOOLS Published Updated Last reviewed

Convert any image (JPG, PNG, WebP, GIF, SVG) to Base64 instantly. Drag-and-drop or click to upload. Toggle the data URI prefix, copy to clipboard, or download as text. Free.

RT-IMG-003 · Image & File
Your browser is too old for this tool’s interactive features. Please update to Safari 13.1, Chrome or Edge 80, Firefox 74 or newer.

Image to Base64 Tool

Drop your image here or click to browse
JPG, PNG, WebP, GIF, SVG · Max 5 MB
Advertisement
After results · AD-W1 Responsive · Post-tool — peak engagement

How to Use the Converter

1

Drop or upload an image

Drag an image into the drop zone, or click it to browse. JPG, PNG, WebP, GIF and SVG are supported up to 5 MB.

2

Review the preview

The image preview, file size, and Base64 overhead appear immediately so you can verify the file before using its encoding.

3

Toggle the data URI prefix

Keep the prefix on for direct HTML/CSS use; toggle it off if you only need the raw Base64 string.

4

Copy or download

Copy the result to your clipboard or download it as a plain text file for archiving.

About Image to Base64 Encoding

Base64 is a text representation of binary data — an encoding scheme that takes raw bytes (like the contents of a PNG file) and represents them using only 64 printable ASCII characters: A–Z, a–z, 0–9, plus + and /. The trick lets you embed binary content anywhere a text channel exists: inside HTML attributes, CSS files, JSON payloads, email bodies, even SQL columns. The most common use case for images is the data: URI scheme — an image embedded directly as <img src="data:image/png;base64,iVBORw0KGgo…"> rather than referenced by URL. The browser decodes it on the fly and renders the image without making a separate HTTP request.

Base64 came to email with MIME (Multipurpose Internet Mail Extensions): RFC 1341 defined it in June 1992, the current MIME text is RFC 2045 (1996), and RFC 4648 (2006) is the general definition — which is why an email's PDF attachment is Base64 under the hood. The number 64 comes from the math: 6 bits per character (2⁶ = 64), and three bytes (24 bits) of input map cleanly to four characters of output. This 3-to-4 ratio is also why Base64 adds approximately 33% to the file size — the price you pay for binary-as-text portability.

Base64 isn't compression — it's the opposite. Three bytes of binary become four characters of text: a third larger, for the convenience of embedding anywhere a string can go.

When to use Base64 (and when not to)

The classic good use cases: tiny icons under 2 KB (sub-tab icons, status pips, inline SVG decorations), critical above-the-fold images on a slow connection (where eliminating a TCP round-trip is worth 33% extra payload), and inline image data in JSON APIs where the client expects everything in one response. The classic bad use cases: any image over ~10 KB (the 33% overhead becomes a real bandwidth cost), images shared across many pages (each page now embeds the same data instead of caching once), and large images on mobile, where the inflated payload costs anyone on a metered plan. Email is its own case: many clients block remote images by default, but data: images are not a reliable fix either — support varies by client — and the usual method is to attach the image and reference it by cid: (RFC 2392).

Why we encode in your browser

This converter uses the browser's FileReader API to read the file as a Base64 data URL — no upload, no network round-trip, no server-side handling. We chose this approach for three reasons. First, privacy: many use cases involve screenshots of internal dashboards, confidential UI mockups, or proprietary design assets where uploading to a third-party converter is a leak risk. Second, speed: client-side encoding is genuinely instant for files up to a few MB. Third, cost: we don't have to pay for the bandwidth or compute. The trade-off is the 5 MB file size cap — beyond that, browsers start struggling and the resulting string becomes impractical to paste anywhere. For larger images, host them on your CDN and use a regular URL.

Singapore and Malaysia have strong personal-data protection laws (PDPA in both jurisdictions, plus GDPR if you serve EU users). Anything containing recognisable faces, ID numbers, or personal information should never be uploaded to a third-party encoder. Local-only encoding eliminates that risk entirely.

Three bytes become four characters, and a data URL can hold far more than you should put in one

01

Base64 arrived with MIME in 1992. RFC 1341 defined it; RFC 2045 (1996) is the current MIME text and caps encoded lines at 76 characters.

02

The "64" is literal. 6 bits per character → 2⁶ = 64 possible characters. A–Z (26) + a–z (26) + 0–9 (10) + + and / = 64 exactly. = is padding.

03

3 bytes → 4 characters. That's the conversion ratio. It's also why Base64 inflates output by a third (4/3 ≈ 1.33), before padding and any line breaks.

04

data: URIs were specified in 1998. RFC 2397 defined the data:[<mime-type>][;base64],<data> scheme.

05

Size is not the limit you will hit. MDN puts Chromium's and Firefox's data-URL limit at 512 MB and Safari's at 2048 MB — far beyond anything worth embedding, which is why this tool stops at 5 MB.

06

URL-safe Base64 is a thing. Standard Base64 uses + and /, which need URL encoding (%2B, %2F). URL-safe Base64 (RFC 4648) substitutes - and _ instead — common in JWT tokens.

07

SVGs don't need Base64. Because SVG is already text, you can embed it URL-encoded: <img src="data:image/svg+xml,%3Csvg…">. No Base64 overhead. The 33% bloat is the cost of binary-to-text conversion only.

08

Email is the exception. Many clients block remote images by default, and data: images are not reliably shown either; email usually attaches the image and refers to it with a cid: URL (RFC 2392).

09

Embedded images are not cached separately. A data URL is part of the page or stylesheet it sits in, so an image used on many pages is downloaded again with each one.

10

This converter runs locally. Browser FileReader API, no upload, no server-side processing. Safe for confidential screenshots, internal mockups, and anything PDPA-covered. Open DevTools to verify — zero network traffic during encoding.

Frequently Asked Questions

  • Base64 is a binary-to-text encoding scheme that represents binary data (like the bytes of a PNG file) using only 64 printable ASCII characters: A–Z, a–z, 0–9, plus + and /. It lets you embed binary content anywhere a text channel exists — HTML attributes, CSS, JSON payloads, email bodies, SQL columns. The most common image use is the data: URI scheme: <img src="data:image/png;base64,...">.
  • Because Base64 encodes 3 binary bytes (24 bits) using 4 ASCII characters (4 × 6 = 24 bits). That 3-to-4 ratio inflates the output by roughly 33%. You're paying that overhead for the ability to embed binary content as plain text — there's no way around it; that's the math.
  • It's the data: URI scheme prefix that tells the browser how to interpret the rest of the string. data: declares it's an inline data URL; image/png is the MIME type; base64 signals the encoding. Without this prefix, browsers won't render the data correctly when used in <img src> or CSS url().
  • No. The conversion runs entirely in your browser using the FileReader API. Your image bytes never leave your device. Verifiable in DevTools — zero network traffic during encoding. Safe for screenshots of confidential dashboards, internal design assets, and any image covered by PDPA / GDPR.
  • We cap inputs at 5 MB. Beyond that, browsers struggle and the resulting Base64 string (which inflates by 33%) becomes impractically long to paste or transmit. For larger images, host them on your CDN and use a regular URL — that's almost always more efficient.
  • Three good cases: (1) very small images under 2 KB — sub-tab icons, status pips, inline decorations where the HTTP round-trip costs more than the 33% bloat; (2) a critical above-the-fold image where saving a request matters more than the extra third; (3) JSON APIs that need to return image data alongside other fields in a single response.
  • Avoid Base64 for: any image over ~10 KB (the 33% overhead becomes a real bandwidth tax), images used on many pages (each page embeds a fresh copy instead of caching once), large images on mobile (a metered plan pays for the extra third), and email, where data: images are unreliable — attach the image and use cid: instead.
  • Size is rarely the cause — MDN puts Chromium's and Firefox's data-URL limit at 512 MB and Safari's at 2048 MB. More often the string was cut when pasted, the MIME type does not match the image, or the prefix is missing. Check that the string ends where the tool's output ends and starts with data:image/…;base64,.
  • Standard Base64 (RFC 4648) uses + and / as two of its 64 characters. Both need URL-encoding (%2B, %2F) when used in URLs. URL-safe Base64 substitutes - and _ instead, so the string can be used directly in URLs without further encoding. JWT tokens use URL-safe Base64. This converter outputs standard Base64.
  • Any image format your browser can read — PNG, JPEG, GIF, WebP, SVG, BMP, AVIF, and others. The output is always a data: URI string with the correct MIME type prefix detected from the input file. Copy the full string for direct embedding, or copy just the Base64 portion if you need to use it elsewhere.
Advertisement
After how-to · AD-W2 Responsive

Method & sources

How it computes

Reads the image with the browser's FileReader.readAsDataURL (no upload), caps input at 5 MB, and shows the Base64 string with or without the data: prefix and its size overhead against the original file.

What this tool implements

  • RFC 4648: Base64 encodes 3 bytes as 4 characters from a 64-character alphabet, hence the one-third overhead; MIME introduced it in RFC 1341 (June 1992) — the page said 1996 — and RFC 2045 caps encoded lines at 76 characters.
  • MDN: Chromium and Firefox accept data URLs up to 512 MB and Safari 2048 MB — the page's "Chrome caps data URIs at 2 MB" fact and heading were out of date.
  • The page called Base64 "the only reliable way" to put a logo in email; data: images are not reliably shown there, and email references attached images by cid: (RFC 2392).

Sources

Advertisement
Pre-footer · AD-W3 728 × 90