Which Base64 standard does the tool follow?

RFC 4648 (Simon Josefsson, IETF October 2006, Standards Track) — the current canonical Base64 specification, obsoletes RFC 3548 from July 2003. The encoder uses FileReader.readAsDataURL() per the W3C File API spec (w3c.github.io/FileAPI), referenced from the WHATWG HTML Living Standard — a native browser API that asynchronously reads the source file and emits a complete data URI with MIME auto-detected from the file's type property. Base64's earliest IETF appearance was RFC 989 by John Linn at BBN Communications Corporation (IETF February 1987, PEM Part I — Message Encipherment and Authentication Procedures; obsoleted by RFC 1040 in 1988 then RFC 1113 in 1989), and the canonical pre-RFC 4648 spec was RFC 2045 MIME by Freed & Borenstein, IETF November 1996.

What is the size overhead of Base64 vs raw binary?

Exactly 4/3, or ~33.33% larger. Every 3 source bytes encode as 4 ASCII characters from the 64-character alphabet (A-Z + a-z + 0-9 + + + /), with `=` padding to align the output to a multiple of 4 characters per RFC 4648 §4. For a 12 KB PNG that's ~16 KB of Base64 text; for a 100 KB JPG that's ~133 KB. The overhead is the cost of representing binary in 6-bit-per-character ASCII.

When should I use a data URI vs raw Base64?

Data URI (full `data:image/ ;base64, ` form per RFC 2397, Larry Masinter, Xerox Corporation, IETF August 1998 Standards Track) when you're embedding directly in HTML ` ` or CSS `background-image: url(data:...)` — browsers parse the prefix to know the MIME. Raw Base64 (just the payload) when the consumer already knows the MIME from context: JSON API fields, custom protocols, configuration files, tests. The tool exposes both via separate copy buttons.

When should I avoid Base64-inlining an image?

Large files (>10 KB raw is the common rule of thumb). The ~33% size overhead + cache-unfriendliness (the data URI can't be cached by the browser like a separate file can; it has to be re-downloaded with the parent document every time) usually outweigh the saved HTTP request. For small icons, logos, decorative graphics, favicons, or single-use email attachments, inlining is a net win. For large photos or assets reused across pages, serve as regular files.

Image to Base64 Encoder Online — RFC 4648 + RFC 2397 data URI via W3C File API FileReader.readAsDataURL

Q: Is my image uploaded?

No. FileReader.readAsDataURL() from the W3C File API runs entirely in the browser. The file is read from your local disk into the page's memory and Base64-encoded synchronously in JavaScript — there is no fetch() call, no XHR, no analytics beacon carrying the file bytes. The encoded string exists only in your tab; it never leaves your device.

Image to Base64 Encoder — RFC 4648 + RFC 2397 data URI via W3C File API FileReader.readAsDataURL

Encode any image file as a Base64 ASCII string per RFC 4648 (Simon Josefsson, IETF October 2006 Standards Track — obsoletes RFC 3548 from July 2003; Base64 history traces back to RFC 989 February 1987 and RFC 2045 MIME November 1996) and a complete data URI per RFC 2397 (Larry Masinter, Xerox Corporation, IETF August 1998 Standards Track — the `data:[<mediatype>][;base64],<data>` URL scheme). The encoding runs locally via FileReader.readAsDataURL() per the W3C File API spec (w3c.github.io/FileAPI), referenced from the WHATWG HTML Living Standard — a native browser API that asynchronously reads the source file and emits a complete `data:image/<mime>;base64,<payload>` URL where the MIME is auto-detected from the file's type property. The tool exposes both forms via separate copy buttons: the FULL data URI (`data:image/png;base64,iVBORw0KGgoAAAA...`) for direct embedding in `<img src='...'>` HTML attributes or `background-image: url(data:...)` CSS, AND the RAW Base64 payload (everything after the comma) for consumers that already know the MIME type (JSON API payloads, configuration files, custom protocols). Base64 expands binary by exactly 4/3 (~33%): every 3 bytes of source binary become 4 ASCII characters from the 64-character alphabet (A-Z + a-z + 0-9 + + + /), with `=` padding to the nearest multiple of 4. Files never leave the device.

How to encode an image as Base64

Drop your image onto the tool or click to browse. The browser's File API exposes the binary data + MIME type to a FileReader instance (W3C File API).
The tool calls FileReader.readAsDataURL() — a native browser API that asynchronously reads the file and emits a complete `data:image/<mime>;base64,<payload>` URL when the `onload` callback fires.
Choose which form you need from the two copy buttons: the FULL data URI (for `<img src='data:image/png;base64,iVBOR...'>` HTML or `background-image: url(data:...)` CSS) OR the RAW Base64 payload (for JSON API bodies + configuration files that already know the MIME type).
Click Copy on the chosen form to put the string on your clipboard via navigator.clipboard.writeText(). The Copy button confirms with a brief check icon for 2 seconds.
Paste the string into your target context. The original file stays on disk untouched — files never leave the device.

Common use cases

Inlining small icons / logos / decorative graphics directly in HTML or CSS to eliminate separate HTTP requests and reduce render-blocking RTTs on initial page load.
Embedding an image inside a JSON API payload where binary multipart upload isn't supported (common in serverless functions and edge-worker request bodies).
Shipping a self-contained single-file HTML demo, prototype, or proof-of-concept that carries its own image assets without external dependencies.
Pasting a logo into an email template where the recipient's client blocks external image loading (common in Gmail, Outlook, corporate email gateways).
Generating data URIs for SVG sprite previews, favicon embedding via `<link rel='icon' href='data:...'>`, or storyboard / Figma-style design system documentation.

Frequently asked questions

Is Base64 always a good idea for images?

No. Base64 adds exactly 4/3 (~33%) size overhead per RFC 4648 — every 3 source bytes become 4 ASCII characters. The data URI form also can't be browser-cached the way a separate asset URL can (each page that inlines the same image ships its own copy). For images above ~10 KB raw, the request-elimination savings rarely beat the size overhead + cache-unfriendliness. Use Base64 for: small icons (<2 KB), logos (<5 KB), email-embedded images, JSON API payloads, single-file HTML demos. Serve as regular HTTP assets for: larger photos, repeatedly-used images, anything that benefits from HTTP caching.

Which form do I paste into HTML or CSS?

The full data URI form (starts with `data:image/...;base64,`). The `data:` prefix is part of the RFC 2397 (Masinter, IETF August 1998) URL scheme that tells the browser how to interpret the payload as inline image data. Examples: `<img src='data:image/png;base64,iVBOR...'>` in HTML, or `background-image: url(data:image/png;base64,iVBOR...)` in CSS. The raw Base64 payload (without the `data:image/...;base64,` prefix) is only useful when the consumer already knows the MIME type — JSON API bodies, configuration files, custom binary protocols.

Does encoding change image quality?

No. Base64 per RFC 4648 is a lossless byte-to-ASCII text encoding — encoding then decoding produces a byte-identical image to the original. The encoded form is just a different text representation of the same binary bytes; the underlying image format (PNG, JPEG, WebP, etc.) and its quality settings are unaffected. The only 'cost' is the ~33% size overhead of representing 3 binary bytes as 4 ASCII characters.

What MIME types does the tool support?

Any MIME type the browser auto-detects from the File.type property — image/png, image/jpeg, image/webp, image/avif, image/gif, image/svg+xml, image/x-icon, image/bmp, image/tiff (where supported by browser), etc. FileReader.readAsDataURL from the W3C File API emits the data URI with whatever MIME the File API reports for the source file.

Is my image uploaded?

No. The encoding runs entirely client-side via FileReader.readAsDataURL() from the W3C File API — the file never reaches a server. DevTools Network tab shows zero upload requests during encoding. The Base64 + data URI strings live only in your browser memory + clipboard.

RFC 4648 Base64 + RFC 2397 data URI + FileReader.readAsDataURL (W3C File API) pipeline

The encoding pipeline uses native browser APIs end-to-end: the source file enters via the W3C File API (w3c.github.io/FileAPI, referenced from the WHATWG HTML Living Standard), passes through FileReader.readAsDataURL() per the same spec (a `FileReader` instance with an `onload` callback that fires when `reader.result` contains the complete data URI string), then the tool splits the result on the first comma to expose both the data URI form (`data:image/png;base64,iVBORw0KGgo...`) AND the raw Base64 payload (`iVBORw0KGgo...`). The Base64 encoding itself follows RFC 4648 (Simon Josefsson, IETF October 2006, Standards Track, obsoletes RFC 3548 July 2003) — every 3 source bytes encode as 4 ASCII characters from the 64-character alphabet [A-Za-z0-9+/], with `=` padding to align to a multiple of 4 characters; this produces an exact 4/3 size expansion (~33.33% overhead) versus the raw binary input. Base64's history in IETF tracks back to RFC 989 (Linn, BBN Communications Corporation, February 1987, PEM Part I — Message Encipherment and Authentication Procedures; obsoleted by RFC 1040 in 1988 then RFC 1113 in 1989) and RFC 2045 (Freed & Borenstein, IETF November 1996, MIME Part One). The data URI scheme is RFC 2397 (Larry Masinter, Xerox Corporation, IETF August 1998, Standards Track) — defines the `data:[<mediatype>][;base64],<data>` URL syntax with `;base64` extension distinguishable from a content-type parameter by the absence of a following `=` sign. The default MIME if omitted is `text/plain;charset=US-ASCII` per the RFC, but for image data the MIME is always explicit (image/png, image/jpeg, image/webp, image/avif, image/gif, image/svg+xml — although see the base64-to-image tool for SVG XSS hardening notes). Practical use cases: inline small images (icons, logos, favicons, decorative graphics) directly in HTML/CSS to eliminate HTTP requests + reduce render-blocking RTTs; embed images in JSON API payloads where multipart-binary upload isn't supported; ship self-contained single-file HTML demos with their own image assets; paste logos into email templates where external image loading is blocked. Anti-pattern: large images (>10 KB raw) usually shouldn't be Base64-inlined because the ~33% size overhead + cache-unfriendliness (the data URI can't be cached by the browser like a separate file can) outweigh the saved HTTP request — for those, serve as a regular asset.

Base64 encoding per RFC 4648 (Josefsson, IETF October 2006, Standards Track) — obsoletes RFC 3548 July 2003; Base64 history RFC 989 (Linn, BBNCC, February 1987) + RFC 2045 November 1996
Data URI per RFC 2397 (Masinter, Xerox, IETF August 1998, Standards Track) — `data:[<mediatype>][;base64],<data>` URL syntax
FileReader.readAsDataURL() native browser API per W3C File API spec (w3c.github.io/FileAPI), referenced from the WHATWG HTML Living Standard
Outputs BOTH forms: full data URI (for `<img src='...'>` + CSS background-image) AND raw Base64 payload (for JSON API + custom protocols)
One-click copy to clipboard via navigator.clipboard.writeText() for both forms
Displays Base64 + data URI character lengths for reference (data URI = data:image/<mime>;base64, prefix + raw payload)
~33% size overhead per RFC 4648 (4 ASCII chars per 3 source bytes) — anti-pattern: large images (>10 KB raw) shouldn't be inlined
Browser-side via W3C File API FileReader — no upload, no server, MIME auto-detected from File.type

Free. No signup. No file uploads. Ads via AdSense (consent required).

Sources (7)

Josefsson, S. (SJD) (2006). The Base16, Base32, and Base64 Data Encodings. RFC 4648, IETF (October 2006, Standards Track) — obsoletes RFC 3548 (July 2003); canonical Base64 specification (alphabet A-Z + a-z + 0-9 + + + /, padding `=`, 4-to-3 ASCII-to-byte expansion); §4 defines standard Base64.
Masinter, L. (Xerox Corporation) (1998). The 'data' URL scheme. RFC 2397, IETF (August 1998, Standards Track) — defines `data:[<mediatype>][;base64],<data>` URL syntax (parameters live inside mediatype per BNF); default MIME `text/plain;charset=US-ASCII`; `;base64` extension distinguishable from content-type parameter by absence of following `=`.
Freed, N. (Innosoft) & Borenstein, N. (First Virtual Holdings) (1996). Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, IETF (November 1996, Standards Track) — §6.8 defines pre-RFC 4648 canonical Base64 for MIME; precedes RFC 3548 (2003) and RFC 4648 (2006).
Linn, J. (BBN Communications Corporation) (1987). Privacy Enhancement for Internet Electronic Mail: Part I — Message Encipherment and Authentication Procedures. RFC 989, IETF (February 1987) — first IETF appearance of Base64 encoding for PEM message bodies; obsoleted by RFC 1040 (January 1988) then RFC 1113 (August 1989); Part III algorithms specified separately in RFC 1115 (Linn, DEC, August 1989); superseded by RFC 4648.
W3C Web Applications Working Group (live). File API — FileReader.readAsDataURL(). w3c.github.io/FileAPI — W3C Working Draft; FileReader.readAsDataURL() asynchronously reads a File/Blob and emits `data:<MIME>;base64,<payload>` URL via `result` on the `load` event with MIME from the file's `type` property.
W3C Web Applications Working Group (live). File API — File + Blob + FileReader interfaces. w3c.github.io/FileAPI — File interface inherits Blob; FileReader provides readAsArrayBuffer/readAsText/readAsDataURL with onload/onerror callbacks; referenced from WHATWG HTML Living Standard.
WHATWG (live). HTML Living Standard — File API references and integration. html.spec.whatwg.org — references the W3C File API spec for File/Blob/FileReader interfaces used across the platform.

These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.