File to Base64

This tool encodes the contents of a file as a base64 string in your browser. The file never leaves your machine — the encoding happens locally with the browser’s FileReader API (readAsDataURL). The output is the same base64 form covered in base64 encode; this page is about when to encode a whole file rather than send it as binary.

Why encode a file at all

Most contexts that carry data carry text. JSON is text. HTTP headers are ASCII. SMTP-era email was 7-bit. CSS and HTML are text. If you need to transmit a binary file (an image, a PDF, a font, a serialized blob) through one of those text-only channels, you have to encode it. Base64 is the standard envelope: it represents arbitrary bytes using printable ASCII characters at the cost of a ~33% size increase.

The size cost

Raw file:        100 KB
Base64-encoded:  ~133 KB

Base64 emits 4 ASCII characters per 3 input bytes. The factor is exactly 4/3 ≈ 1.333×, plus padding (a couple of = characters at the end if the input length isn’t a multiple of 3). For most files this is bearable; for some it is decidedly not.

The break-even depends on what you’re optimizing. For email attachments, base64 has been mandatory for decades because SMTP can’t carry binary. For HTTP, multipart/form-data lets you ship binary directly; encoding to base64 first wastes bandwidth.

Common targets for file-to-base64

• Data URIs in HTML/CSS. <img src="data:image/png;base64,iVBOR..."> inlines the image so the page is a single self-contained file. Useful for tiny icons (saves a request); harmful for anything larger than a few kilobytes (loses caching, bloats the HTML).
• JSON API payloads. When a JSON endpoint needs to ship a binary blob (a generated PDF, a profile picture upload, a public key), base64-encoded into a string field is the conventional form.
• Email attachments. MIME’s Content-Transfer-Encoding: base64 is how every binary attachment travels.
• Database BLOB fields. Storing binary as base64 strings is wasteful (33% larger) but eliminates encoding mismatches across drivers. Most modern databases support binary types directly; prefer those.
• Configuration files. Embedding a small binary credential (a TLS private key, a service-account JSON) into a config that’s otherwise text-only.

When not to base64

• HTTP file uploads. Use multipart/form-data — designed for binary, no encoding overhead.
• Large files anywhere. A 50 MB base64 payload is 67 MB on the wire. Use binary transport.
• Streaming data. Base64 is block-based (3 input bytes → 4 output chars); streaming is awkward. Use binary or a streaming-friendly encoding.
• CDN-served assets. A base64 data URI defeats caching — the asset is duplicated into every page that references it. Serve the file separately.

Browser limits

Encoding a multi-gigabyte file in the browser will likely run out of memory. The FileReader holds the input bytes; btoa produces the output string; both occupy memory simultaneously. Practical browser limits are around 100–500 MB of input depending on platform, with substantial slowdown well below that.

For large files that genuinely need to travel through a text-only channel, server-side streaming base64 encoders are the answer. Browser-side encoders (this one included) are for sub-100 MB workflows.

What the encoded output looks like

Input file: hello.txt containing "Hello, world!"
Base64:    SGVsbG8sIHdvcmxkIQ==

The trailing == indicates two bytes of padding (input length 13 isn’t a multiple of 3). For URL or header use, switch to base64url which omits the +, /, and (often) = characters; see base64 encode for the variant differences.

Decoding the output

Most base64 decoders accept the output of any base64 encoder. To turn the string back into a file, you need a decoder that can write binary — most browser tools (including base64 decode) decode to text and need a “save as file” step. Server-side, base64 -d (Linux), Convert.FromBase64String (.NET), base64.b64decode (Python) all return bytes.

Common pitfalls

• Forgetting to set the MIME type in a data URI. data:base64,... (no MIME) defaults to text/plain;charset=US-ASCII, which renders as text rather than as the intended binary type. Always include the MIME: data:image/png;base64,....
• Storing huge base64 blobs in JSON. A 5 MB image becomes a 6.7 MB string in the JSON, which then has to be JSON-escaped (no expansion for base64 chars but the JSON parser still has to lex it). Performance suffers. Use a separate file URL.
• Treating base64 as security. Encoding does not protect contents — anyone can decode it. If you base64-encode a secret thinking it’s now obscured, you’re publishing the secret.
• Pasting a base64 image into a context that expects only ASCII text. Many systems silently truncate at line-length limits or at non-printable characters. Verify the destination accepts the full encoded length.

For the inverse direction, see base64 decode.