Free Base64 File Encoder
Convert any file to a Base64 data URL · everything stays in your browser.
Drag & drop a file here
or
Select or drop a file to encode.
How It Works
- Upload your file: Drop any file (image, PDF, font, audio, or binary) onto the drop zone or click to browse.
- Get the Base64 string: The file is read and encoded to Base64 instantly in your browser.
- Copy and use: Copy the Base64 string to embed in HTML, CSS, JSON payloads, data URIs, or any text-based format.
Why Use Base64 File Encoder?
Binary files cannot be embedded directly in text-based formats like HTML, CSS, JSON, or XML. Base64 encoding converts any binary file into a safe ASCII string that can be embedded anywhere text is allowed. This is essential for embedding images directly in HTML (data URIs), including fonts in CSS, sending files in email or JSON APIs without file upload endpoints, and creating self-contained HTML documents.
Features
- Any file type: Encodes images, PDFs, fonts, audio, video, and all binary files.
- Data URI output: Toggle to get a ready-to-use data URI (data:mime/type;base64,...) for direct embedding.
- File size display: Shows original and encoded sizes so you know the overhead.
- Local processing: Files are read and encoded entirely in your browser, nothing is uploaded.
Frequently Asked Questions
How much larger is Base64 compared to the original file?
Base64 encoding increases file size by approximately 33%. A 100 KB image becomes about 133 KB when Base64 encoded. This overhead is the trade-off for being able to embed binary content in text.
Can I use Base64 images in HTML?
Yes. Use a data URI like <img src="data:image/png;base64,[your-base64]">. This embeds the image directly in the HTML with no external HTTP request, though it increases page size.
Is there a file size limit?
The tool has no enforced limit, but very large files (above 10 MB) may be slow to encode and the resulting string will be extremely long. For large files, consider a server-side solution instead.
Where Base64 came from, and why we still use it
Base64 was designed to carry 8-bit binary data through 7-bit ASCII pipes. The first formal specification was RFC 989 (February 1987) for Privacy-Enhanced Mail. RFC 1341 (June 1992) and especially RFC 2045 «MIME Part One» (November 1996) made it the standard way to attach binary files to email. The current canonical document is RFC 4648 (October 2006), which also defined the URL-safe variant. The mechanics are simple: take 3 bytes of input (24 bits), split into four 6-bit groups, look each up in the 64-character alphabet A-Z a-z 0-9 + /, append = padding to make the output length a multiple of 4. Output size is exactly 4 ÷ 3 ≈ 133 % of the input. For embedding in URLs (JWT, OAuth, S3 pre-signed URLs), the URL-safe variant from RFC 4648 §5 substitutes - for + and _ for /; padding is typically omitted.
The data: URL: Base64 in your HTML and CSS
The data: URL scheme was specified in RFC 2397 (August 1998). Format: data:[<mediatype>][;base64],<data>. Example: <img src=\"data:image/png;base64,iVBORw0KGgo...\"> embeds a PNG inline with no extra HTTP request. The WHATWG URL Living Standard governs how modern browsers interpret these URLs and the HTML Living Standard confirms they are valid wherever a URL is allowed, including <img>, <link>, <iframe>, and the CSS url() function. Practical guidance: use data URLs for assets under about 4 KB, where saving one HTTP request beats the 33 percent payload bloat. Above 10 KB, regular file references with browser caching almost always win, especially over HTTP/2 multiplexing.
Browser APIs powering this tool
This page uses the FileReader API from the HTML Living Standard (originally W3C File API First Public Working Draft November 2009; shipped in Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10). FileReader.readAsDataURL(blob) returns the complete data:<mime>;base64,<...> string with one call. The legacy alternative is btoa() (named for the historical Unix «binary-to-ASCII» command and a JavaScript DOM Level 0 holdover), but it throws on non-Latin-1 input unless you transcode through UTF-8 first. The modern replacement is Uint8Array.prototype.toBase64(), added to ECMAScript 2025 at TC39 Stage 4. It shipped in Chrome 132 (January 2025), Firefox 133 (November 2024), and Safari 18.2 (December 2024). Use the new API for any new code; reserve btoa for compatibility with older browsers.
Where the output of this tool actually goes
- Inline icons and small images in HTML / CSS for self-contained or offline-first documents.
- JSON file-upload payloads when the backend expects a Base64 string in a JSON field rather than
multipart/form-data. - MIME email attachments: RFC 2045 requires Base64 (or quoted-printable) for any non-7-bit body, which means every PDF, image, or doc attachment.
- JWT / OAuth tokens: every JWT is three URL-safe Base64 segments joined by
.. - Test fixtures committed to git, so test images / sample documents travel with the test file.
- Web Push payloads when delivering a binary blob through the Push API.
- Critical-path web fonts embedded in CSS for first-paint avoidance of FOIT (flash of invisible text), trade-off accepted.
Common mistakes
- Treating Base64 as encryption. Base64 is encoding, not security. Anyone with the string can decode it in their browser. Never use Base64 to «hide» credentials, API keys, or PII.
- Forgetting the
data:<mime>;base64,prefix. A bare Base64 string is not a data URL. An<img>needs the fulldata:image/png;base64,<your-base64>form to render. - Mixing URL-safe and standard Base64. JWT and S3 pre-signed URLs use URL-safe (
-and_). Pasting standard Base64 (+and/) into these contexts yields silent decode failures. - Forgetting the CSP
data:directive. A page withimg-src 'self'in its Content Security Policy will refuse to load anydata:image/...URL. You have to explicitly allowimg-src 'self' data:(and similarly forfont-src,media-src, etc.). - Encoding 100 MB files synchronously on the main thread.
FileReader.readAsDataURLblocks the UI for several seconds on a 200 MB file. For anything over ~20 MB, use a Web Worker or stream chunks. - Calling
btoa("é")directly. It throwsInvalidCharacterErrorbecausebtoaexpects Latin-1, not UTF-8. Either usebtoa(unescape(encodeURIComponent(text)))(legacy), or pass aUint8Arraythrough the moderntoBase64()method. - Inlining a 500 KB logo as a data URL. The 33 percent bloat plus loss of browser caching means every page load downloads 665 KB instead of 500 KB-once. Use a regular asset reference.
More frequently asked questions
What is the exact size overhead of Base64?
Exactly 4 ÷ 3 ≈ 1.333× the input, plus 1-2 bytes of = padding. A 999-byte input becomes 1332 characters of Base64 (no padding because 999 ÷ 3 = 333 exactly). A 1000-byte input becomes 1336 (one byte of padding). For a data URL, add the prefix bytes (e.g. data:image/png;base64, is 23 characters).
How do I get URL-safe Base64 for JWT or S3 pre-signed URLs?
Take the standard Base64 output from this tool and apply two replacements: + → -, / → _. JWT specifically strips the trailing = padding; S3 keeps it. RFC 4648 §5 documents the variant.
Can I round-trip a file through Base64 without corruption?
Yes. Base64 is a lossless encoding. Encoding to Base64 then decoding back produces a byte-identical original. The only way to lose data is to truncate the Base64 string (e.g. character-limit your storage) or to confuse standard vs URL-safe alphabets when decoding.
What is the maximum file size this tool can handle?
No hard limit; in practice browser memory is the ceiling. Encoding a 100 MB file requires roughly 100 MB of input plus 133 MB of output, plus DOM overhead for the result string, perhaps 400 MB total. On mobile, expect failures over about 30 MB. The encoding runs on the main thread, so the UI freezes during processing; for files over 20 MB, a server-side or Web Worker solution is more comfortable.
Is my file uploaded anywhere?
No. The file is read with the browser's FileReader.readAsDataURL API, which runs entirely in your browser. No network request is made and no copy of your file is stored on any server. Open the Network tab in DevTools and drop a file in: you will see zero outgoing requests during the encoding.