Base64 Encoder, built right. Free, fast, and accurate to the byte.

Why encode anything to Base64

Base64 encoding takes binary data — bytes that may include unprintable characters, control codes, and high-bit values — and converts it to a string of 64 printable ASCII characters. The reason to do this is almost always the same: you need to send binary content through a system that was designed for text. Email is text. JSON is text. HTML attributes are text. URLs are text. Database VARCHAR columns are text. When you want to put an image, a PDF, an encrypted blob, or any other binary content into one of those systems, Base64 is the universal wrapper.

It is not encryption — Base64 is fully reversible without a key. It is not compression — the encoded form is actually 33% larger than the original. It is not a security measure of any kind. It is purely a transport encoding, designed in 1996 to safely move binary attachments through email systems that mangled anything that was not 7-bit ASCII.

When to encode to Base64

The common scenarios all share a pattern: you have binary data, and the destination only accepts text. Embedding images in HTML or CSS uses Base64 data URIs to inline small images and eliminate separate HTTP requests. API payloads with file uploads often Base64-encode the file inside a JSON body, sparing the caller from constructing multipart form data. Email attachments are Base64-encoded inside MIME messages because SMTP cannot reliably carry arbitrary binary. Configuration files (YAML for Kubernetes, JSON for cloud functions) sometimes need binary secrets, keys, or certificates inline. HTTP Basic Authentication Base64-encodes the username and password (a poor security choice in 2026, but still ubiquitous). Generating signed URLs and JWTs requires URL-safe Base64 encoding of payloads and signatures.

You should not use Base64 when binary transport is available. Multipart form uploads, gRPC streams, raw POST bodies with the correct Content-Type, and binary WebSocket frames are all more efficient. The 33% size penalty matters at scale — encoding a 100 MB file produces 133 MB of text. For bulk data, native binary protocols win every time.

Step-by-step: encoding text to Base64

Paste or type your text into the plain text input at the top of this page. The encoder runs immediately if "Live mode" is enabled (it is, by default), or you can press the Encode button. The encoded Base64 appears in the output box, and the stats panel shows the input length, output length, and which encoding variant was used.

The output style selector controls the variant. Standard Base64 (RFC 4648 §4) is the universal default — A-Z, a-z, 0-9, plus + and /, with = padding. Use this for almost everything: API request bodies, database storage, MIME-less email content, configuration files. URL-safe Base64 (- and _) replaces + with - and / with _, so the encoded string can safely appear in URLs and filenames without percent-encoding. Required for JWTs, OAuth PKCE, and many query-string-embedded tokens. URL-safe, no padding additionally drops the trailing = characters. This is the JWT-flavored variant — JWTs always omit padding. MIME (76-character line wrap) breaks the output into 76-character lines, required by email MIME messages and some legacy systems. Modern JSON and HTML accept unwrapped Base64 without issue, so MIME wrapping is rarely needed outside of email.

Step-by-step: encoding a file to Base64

For binary content, paste-and-encode does not work — you need a way to read the raw bytes of a file. Drop a file onto the upload zone, or click to browse. The encoder reads the file using the browser's FileReader API, encodes it in the selected variant, and shows the result in the output box. Large files (over 200 KB) are encoded in chunks to keep the browser responsive — you will see progress in the status indicator.

The 50 MB file size limit is a practical browser ceiling. JavaScript can handle larger files in principle, but the encoding process becomes slow (multi-second hangs) and the resulting Base64 string can exceed text-input rendering limits in some browsers. For files larger than 50 MB, use a command-line tool: base64 myfile.bin on macOS and Linux, or certutil -encode myfile.bin out.txt on Windows.

Choosing the right encoding variant

The four variants are not equivalent for every use case. Picking the wrong one is one of the most common sources of "the API rejected my payload" errors. Quick guide: Standard Base64 for API request bodies, database columns, file uploads, and most general use. URL-safe for tokens in URL query parameters, filenames, OAuth flows, and anywhere the output will appear in a URL or path. URL-safe no padding for JWTs, OAuth 2.0 PKCE code verifiers, and modern token formats that follow JWT conventions. MIME for email attachments, certificate request bodies (PEM format), and legacy protocols that require line wrapping.

If the destination documentation does not specify a variant, default to Standard Base64. It is what 95% of systems expect when they say "Base64-encoded".

Common encoding gotchas

The encoded output has trailing equal signs but the API rejects it. The API probably wants the no-padding variant. Switch the output style to "URL-safe, no padding" and re-encode.

The output has line breaks but the API wants a single line. You selected the MIME variant. Switch to standard Base64 and the output will be one continuous string.

The encoded string contains + and / but appears in a URL. Those characters are valid Base64 but have special meaning in URLs (+ means space in form data, / is a path separator). Switch to URL-safe encoding so the output uses - and _ instead.

The byte count looks wrong for my text. Multi-byte character encodings (UTF-8, UTF-16) inflate the byte count beyond the character count. "café" is 4 characters but 5 bytes in UTF-8. Base64 encoding represents bytes, so an emoji-heavy 100-character string can produce 200+ Base64 characters of output.

The encoding seems to corrupt my data. Almost always a character-set issue. Make sure your input is interpreted as UTF-8 (the standard for modern content) before encoding. If you have legacy Windows-1252 content, you may need to convert it first.

Generating data URIs

A common encoding goal is to produce a data URI — a complete URL that contains the encoded content inline, like data:image/png;base64,iVBORw0KGgo.... Data URIs can be used anywhere a regular URL would work: src attributes in HTML, background-image in CSS, href for downloadable content. They eliminate the HTTP request that would otherwise be needed to fetch the resource.

This tool produces just the Base64 portion. To form a data URI, prepend the MIME type and the ;base64, marker: for example, data:image/png;base64, + your encoded string. Our format-specific tools — Image to Base64, PDF to Base64 — offer a "data URI" output option that wraps the encoded content automatically with the correct MIME prefix.

Privacy: where your data goes

Nowhere. The encoder runs entirely in your browser using JavaScript. The plain text, uploaded files, and Base64 output exist only in your browser tab. There is no server-side encoding, no analytics that capture your input, no logging. The Network tab in DevTools will stay silent during encoding — verify it yourself.

The page loads once (about 200 KB total) and runs entirely offline afterward. Disconnect your network and the encoder still works. This is the right design for a tool that handles potentially sensitive data — keys, tokens, private files, anything you would not paste into a random website.