Data URL Encoder

A `data:` URL is one of those web-platform features that's been quietly useful for twenty years. The first spec is RFC 2397 from 1998 — the year of Windows 98 and the iMac G3. The idea is simple: instead of putting the file's location in the URL, put the file itself. The result is an inline asset with no separate HTTP request.

This tool covers both directions. **Encoding** takes a file you have on disk and produces the `data:<mime>;base64,<encoded>` form that you can paste into HTML, CSS, JSON, an email, or anywhere else that takes a URL. **Decoding** takes a `data:` URL someone gave you and converts it back to a real downloadable file with the correct MIME type and a preview if it's an image. Both directions run entirely in your browser using `FileReader.readAsDataURL` and native `atob`.

When to use a `data:` URL:

- **Small icons in CSS.** A 200-byte SVG arrow embedded as `background-image: url(data:image/svg+xml,...)` saves a round trip and ships with the stylesheet. Most modern UI frameworks (Tailwind, Bootstrap) do this for their built-in iconography. - **Self-contained HTML files.** A page that needs to work offline (a generated report, an email-friendly newsletter, an air-gapped tool) can embed every image, font, and CSS file as `data:` URLs so the document is one big self-sufficient blob. - **Email-embedded images.** Outlook and most email clients support `data:` URLs in HTML email. Embed your logo as a `data:` URL and recipients see it inline, no remote fetch, no spam-filter "external image blocked" notice. - **JSON payloads carrying small binaries.** An API that returns "a thumbnail and some metadata in one response" can put the thumbnail inline as a `data:` URL in the JSON, sparing the client a second fetch.

When NOT to use a `data:` URL:

- **Large assets.** A 1 MB image becomes a 1.34 MB data URL, and the browser can't cache it independently. The HTTP cache, with its proper `Cache-Control` and `ETag` story, dominates on anything over ~10 KB. - **Assets shared across many pages.** A regular URL gets cached once; a `data:` URL gets re-parsed for every page it's embedded in. Logos, common icons, framework CSS — these all want regular URLs. - **Anything that needs lazy loading.** The browser can't lazy-load a `data:` URL — the moment the parent element is parsed, the bytes are there. For long lists of below-the-fold images, separate URLs let the browser skip them until they scroll into view.

The format itself is straightforward: `data:[<mime-type>][;<param>]*[;base64],<data>`. The `<mime-type>` is the file type (`image/png`, `text/plain`, `application/json`, etc.). The optional `;base64` flag indicates that `<data>` is base64-encoded; without it, the data is URL-encoded text. There can be parameters like `;charset=utf-8` between, though they're rarely used.

The **base64 vs URL-encoded** choice is a function of what's in the data:

- **Binary data** (images, fonts, PDFs, anything with bytes outside ASCII) must use base64. The ~33% size penalty is unavoidable; URL-encoded binary would be even larger. - **Plain ASCII text** can use URL encoding (`data:text/plain,Hello%20World`). This works for short SVG snippets and short text payloads. For anything over a few hundred bytes the difference is rounding error. - **SVG specifically** is interesting: it's text, so URL encoding works, but URL encoding can be smaller than base64 for SVG because SVG has so much ASCII (`<svg`, `<path`, `xmlns=`). The Web Performance crowd argues hot.

This tool always encodes to base64 (the safer default for unknown inputs). The decoder accepts either form transparently.

A few practical notes:

**Newlines inside data: URLs are removed.** Some pretty-printed examples have line breaks for readability; real browsers strip them on parse. This tool produces a single unbroken string.

**MIME type detection on decode.** The decoder extracts the MIME type from the URL itself; it doesn't sniff the bytes. If the URL says `data:image/png` but the bytes are actually JPEG, the file extension on the download will be `.png` (wrong) but the bytes are still correct (recoverable with a rename). If the URL has no MIME type at all (`data:,...`), the decoder defaults to `application/octet-stream` and downloads as `.bin`.

**Preview is image-only.** The decoder shows an inline preview only when the MIME type starts with `image/`. For PDFs, fonts, JSON, etc., the Download button is the way out.

**Privacy.** Everything runs in your tab. The encoder uses `FileReader.readAsDataURL` which is a browser built-in; the decoder uses native `atob` and `decodeURIComponent`. There are no network requests, no third-party services, no server round-trips. Encode a sensitive document, paste a private screenshot — none of it touches anything outside your machine. Verify in DevTools by watching the network panel stay empty during operation.

**Edge cases handled:** missing MIME type defaults to `application/octet-stream`; non-standard MIME types pass through verbatim; URL-encoded form supported alongside base64; multi-line input (with whitespace and newlines) is trimmed before parsing; bad input shows a clear error rather than silently producing garbage; the URL.createObjectURL lifecycle is properly cleaned up on unmount so blob URLs don't accumulate across multiple decodes.