Introduction: Any File Can Become Base64 Text
One of the most common questions developers ask is which file types can be sent as Base64. The short answer is all of them. Base64 does not care whether the bytes it receives came from a JPEG, a PDF, an MP3, a ZIP archive, a Word document, or a raw cryptographic key. It operates on bytes, not file formats. Every file on disk is ultimately a sequence of bytes from 0 to 255, and Base64 turns any such sequence into safe, printable text.
This makes Base64 the universal adapter for moving files through channels that were built for text rather than binary: email bodies, JSON API payloads, HTML and CSS documents, copy-paste buffers, QR codes, and configuration files. If you have already read our guide to how Base64 works or our Base64 in web development guide, you know the algorithm and its role in tokens and URLs. This article is different: it focuses on files and documents — what you can encode, exactly how much bigger the output gets, and when Base64 is the right transport versus raw binary.
What Types of Files Can Be Sent as Base64?
Because Base64 encodes bytes, the file's format, extension, and origin are irrelevant. Any file you can read from disk can be encoded. In practice you will encounter these categories most often:
- Images: PNG, JPEG, GIF, WebP, SVG, and ICO files are routinely encoded for data URIs and JSON APIs.
- Documents: PDF, DOCX, XLSX, and plain-text files travel as Base64 inside email attachments and web service calls.
- Audio and video: MP3, WAV, and short MP4 clips can be embedded, though their size makes this rarely advisable (more on that below).
- Archives and binaries: ZIP, TAR, and even executables encode cleanly — Base64 never inspects or validates the content.
- Keys and certificates: The familiar PEM format wraps Base64-encoded binary between
-----BEGIN-----and-----END-----markers.
The rule is simple: if it is a file, it can be Base64-encoded. The real question is never can you encode it, but should you — and that comes down to size. You can try any file yourself with our browser-based Base64 encoder/decoder, which processes everything locally without uploading a single byte.
The 33% Size Overhead: Why Base64 Is Always Bigger
Base64 is not free. Turning bytes into printable text always makes the data larger, and the increase is remarkably consistent: about 33%. The reason is structural. Base64 reads your file three bytes (24 bits) at a time and re-splits those 24 bits into four groups of six bits, mapping each group to one printable ASCII character. So every 3 bytes of input become 4 bytes of output — a 4:3 ratio, which is a one-third increase. MDN's Base64 glossary describes the same mechanics behind the browser's btoa() function.
This overhead is a fundamental property of the encoding defined in RFC 4648, not an implementation detail you can tune away. It applies equally to standard and URL-safe variants.
How to Compute the Exact Output Length
You can calculate the encoded length precisely before you encode anything. For an input of n bytes, the standard Base64 output — with padding included — is exactly:
- Output characters = ceil(n / 3) × 4
The ceil (round up) accounts for the final partial group being padded out to four characters with = signs. Because each output character is one ASCII byte, that character count is also the output size in bytes. A few concrete numbers:
- 1 byte → ceil(1/3) × 4 = 4 characters
- 100 bytes → ceil(100/3) × 4 = 34 × 4 = 136 characters
- 3,072 bytes (3 KB) → ceil(3072/3) × 4 = 1,024 × 4 = 4,096 characters (~4 KB)
If you strip padding (as URL-safe Base64 often does), the unpadded length is ceil(n × 4 / 3), which is one or two characters shorter for inputs that are not a multiple of three. Note that MIME Base64 adds even more: a CRLF line break every 76 characters pushes real-world email encoding slightly past the clean 33% figure.
A Worked Size Example
Suppose you want to embed a 3 KB (3,072-byte) icon into an HTML page as a data URI. The Base64 payload is 4,096 characters, so the file grew by 1,024 bytes — the classic one-third tax. Add the data:image/png;base64, prefix (22 characters) and you land at roughly 4.1 KB of text where the original binary was 3 KB. For a small icon that trade is often worth it because you eliminate an entire HTTP round trip. Scale the same math to a 10 MB PDF and the encoded form balloons to about 13.3 MB of text — a very different proposition, and the reason large files should almost never travel as Base64.
Base64 vs Raw Binary: Which Is Better for Storing a File?
A frequent question is whether Base64 or raw binary is the better way to store or move a file. Neither is universally "better" — they solve different problems, and the deciding factor is the channel.
Use raw binary whenever the channel can carry arbitrary bytes end to end. Saving a file to disk, streaming it over an HTTP body with the correct Content-Type, uploading via multipart form data, or transmitting through gRPC or a WebSocket binary frame all handle raw bytes natively. In these cases Base64 only adds 33% of wasted space and needless CPU work. For any large transfer, raw binary is the right answer.
Use Base64 when the channel is text-only and would otherwise corrupt or reject raw bytes:
- Email and MIME: SMTP was historically 7-bit ASCII, so every attachment is Base64-encoded to survive transport.
- JSON payloads: JSON strings must be valid Unicode, so binary fields (a thumbnail, a signature, a small PDF) are carried as Base64 strings.
- Data URIs: Embedding an asset directly in HTML or CSS requires text, so the bytes must be encoded.
- Copy-paste and config files: Anywhere a human or a text editor needs to move the data, Base64 keeps it intact.
The trade-off is therefore not about which format is intrinsically superior for storage, but about whether your transport tolerates binary. If it does, keep the file binary and save the 33%. If it does not, Base64 is the safe, portable choice — and its slightly larger size is the price of guaranteed compatibility across virtually any language or platform.
Data URIs: Great for Small Assets, Wrong for Large Files
A data URI embeds a file's bytes directly inside a document using the form data:[mime-type];base64,[encoded-data]. For example, a tiny logo becomes <img src="">, and the browser reconstructs the image with no separate network request. Used well, this is a genuine performance win.
When Data URIs Help
- Small icons and logos under a few kilobytes, where saving an HTTP request outweighs the 33% growth.
- Critical above-the-fold assets that must render before any additional request completes.
- Single-file deliverables such as a self-contained HTML email or an offline report where nothing external can be fetched.
Why You Should NOT Data-URI Large Files
Data URIs stop being a good idea as the file grows, for reasons beyond the size overhead itself:
- Bloat: The 33% penalty is embedded directly in your HTML or CSS, inflating documents that were meant to be lightweight and quick to parse.
- No caching: An external image is cached once and reused across pages; a data URI is re-downloaded and re-parsed with every document that contains it, because it is part of that document. There is no separate cache entry.
- Blocked rendering and memory: A multi-megabyte Base64 string must be parsed inline before the surrounding markup or stylesheet can finish, and it consumes memory as one large string.
The practical guideline: keep embedded assets small (roughly a few kilobytes), and for anything larger serve the file normally over its own URL with the correct Content-Type header so the browser can cache it and stream it as binary.
Email Attachments: Base64 Behind the Scenes
Every attachment you have ever emailed was Base64-encoded on the way out. Because early email infrastructure assumed 7-bit ASCII text, the MIME standard wraps binary attachments in Base64 (broken into 76-character lines) so a PDF, image, or spreadsheet arrives intact. Your mail client encodes the file before sending and the recipient's client decodes it back to the original bytes — invisibly. This is the single most widespread use of Base64 for documents, and it neatly illustrates the whole principle: a text-only channel, an arbitrary binary file, and Base64 as the bridge between them.
Practical Guidance for Files and Documents
- Small and embedded → Base64. Icons, tiny thumbnails, short signatures, and keys are fine as data URIs or JSON fields; the overhead is negligible.
- Large and standalone → raw binary. Serve big PDFs, videos, and downloads over their own URL with the correct
Content-Type, or upload via multipart form data. Do not Base64 them into JSON. - Predict the size first. Use
ceil(n / 3) × 4to know the encoded length before committing to a transport, especially for payload limits and email quotas. - Lean on compression. If you must send Base64 over HTTP, gzip or brotli recovers much of the 33% because Base64 text compresses well.
- Remember it is not encryption. Base64 makes a document safe to transport, not private. Anyone can decode it — encrypt sensitive files separately.
To experiment with real files and see the exact encoded output and its length, use our free Base64 encoder/decoder. It runs entirely in your browser, supports file upload, and never transmits your documents to a server.