Free Base64 Encoder & Decoder Online

What Base64 Actually Is

Base64 is a binary-to-text encoding scheme, a way to represent any sequence of bytes (binary data) as a sequence of plain ASCII characters that can travel through text-only channels without corruption. The name reflects the alphabet size: 64 characters chosen specifically because they survive 7-bit-clean transmission unchanged. The standard alphabet is A-Z (positions 0-25), a-z (26-51), 0-9 (52-61), then + (62) and / (63). The = character is reserved as padding when the input length isn't an exact multiple of three. Each three input bytes (24 bits) become four output characters (each carrying 6 bits), which is why Base64-encoded data is roughly 33% larger than the original.

The mechanic: take three bytes (24 bits), regroup as four 6-bit chunks, look each chunk up in the 64-character alphabet. The classic worked example: the three ASCII bytes M a n (0x4D 0x61 0x6E) form the 24-bit pattern 01001101 01100001 01101110; regrouped into 6-bit chunks: 010011 010110 000101 101110 = decimal 19, 22, 5, 46 = characters T W F u. So "Man" Base64-encodes to "TWFu". If the input length isn't divisible by three, the encoder pads with one or two = characters: 1 byte input produces 2 chars + ==, 2 bytes input produces 3 chars + =.

A Short History of Base64

Base64 originated in the IETF's Privacy Enhanced Mail (PEM) effort. RFC 989 in February 1987 was the first formal definition; RFC 1113 in August 1989 revised it; RFC 1421 in February 1993 finalised the PEM specification with the Base64 encoding included. Base64 entered the email mainstream when the MIME (Multipurpose Internet Mail Extensions) specification adopted it: RFC 2045 in November 1996 defined Base64 as the standard encoding for binary email attachments, which is why every PDF or image you've ever attached to an email travelled across the wire as Base64. The current canonical specification is RFC 4648 ("The Base16, Base32, and Base64 Data Encodings"), published October 2006 by Simon Josefsson, which superseded RFC 3548 (July 2003) and unified the various Base16 / Base32 / Base64 family encodings into a single document. RFC 4648 is the spec every modern Base64 implementation targets.

URL-Safe Base64, Why Two Characters Get Swapped

The standard Base64 alphabet uses + and /: both of which are reserved characters in URLs. + in a URL query string typically means "space" (form-encoded convention); / is the path separator. Putting standard Base64 in a URL means percent-encoding both, which inflates the string further and makes it ugly. RFC 4648 §5 defines a URL-safe variant: replace + with - (hyphen-minus) and / with _ (underscore). Sometimes called Base64URL or base64url. The result is a string that drops directly into URLs without further escaping, exactly what JWT (JSON Web Tokens), OAuth state parameters, WebAuthn credential IDs, and most modern web APIs use. Some implementations also drop the trailing = padding because the length is implicit from the next field. JWT's three-part dot-separated structure (header.payload.signature) is three Base64URL-encoded segments; if you've ever decoded a JWT manually, you've seen the - and _ characters that mark it as Base64URL rather than standard Base64.

The Base-N Family, Base16, Base32, Base58, Base85

Base64 isn't the only binary-to-text encoding. Base16 (hex) uses 16 characters (0-9 and A-F), 100% size expansion (each byte becomes 2 hex characters), but trivially readable and the universal default for hash output, file checksums and machine identifiers. Base32 (RFC 4648, also Crockford's variant) uses 32 characters with care taken to exclude visually ambiguous pairs like 0/O and 1/I/L; 60% size expansion; used in TOTP secret keys, ULIDs, and Tor onion addresses. Base58 is Bitcoin-canonical: 58 characters excluding the easily-confused 0/O/I/l, plus the standard Base64 special characters +/=. Bitcoin addresses, Solana addresses, and many crypto wallet identifiers use Base58Check (Base58 plus a 4-byte checksum). Base85 / Ascii85 packs more density (encoding 4 bytes as 5 characters, only 25% expansion) but uses an alphabet that includes URL-unsafe punctuation; Adobe's PostScript and PDF formats use Base85 internally for embedded binary data. The general trade-off: more characters in the alphabet means less expansion but a more constrained character set; fewer characters means safer transport at the cost of larger output.

Where Base64 Shows Up in Production

• Email attachments (MIME). RFC 2045 since 1996. Every PDF, image or document you've ever attached to an email travelled the network as Base64 because SMTP was originally a 7-bit-clean text protocol that couldn't handle raw binary.
• data: URIs in HTML/CSS. data:image/png;base64,iVBORw0KGgo... embeds a small image directly into HTML or a CSS stylesheet, eliminating an HTTP request. Useful for icons under ~10 KB; counter-productive for larger images because the 33% Base64 expansion exceeds the HTTP-request overhead saved.
• Binary in JSON payloads. JSON is text-only by spec, there's no way to put raw bytes in a JSON value. APIs that need to transmit images, PDFs or other binary embed them as Base64 strings in a JSON field. Stripe's webhook payloads, Twilio's MMS APIs and many AI-vision endpoints use this pattern.
• JWT (JSON Web Tokens). The three dot-separated parts of a JWT (header.payload.signature) are all Base64URL-encoded. The JWT spec (RFC 7519, May 2015) builds on JOSE (RFC 7515-7518, also May 2015), all of which mandate Base64URL throughout.
• OAuth and OpenID Connect. The state parameter, PKCE code verifiers, ID tokens, and access tokens in many implementations use Base64URL.
• HTTP Basic Authentication. The Authorization: Basic dXNlcjpwYXNz header carries Base64(username:password). Note: this is encoding for transport, NOT encryption, Basic Auth over plain HTTP exposes credentials in plaintext to anyone watching the network. Always pair with HTTPS.
• Subresource Integrity (SRI). The integrity="sha384-..." attribute on <script> and <link> tags carries a Base64-encoded hash of the expected file contents; browsers verify the downloaded file matches before executing.
• SVG-in-CSS backgrounds. background-image: url("data:image/svg+xml;base64,...") embeds an SVG directly in a stylesheet. The Base64 form is sometimes preferred over the URL-encoded form (which keeps the SVG readable but uses different escaping rules).

Encoding Is Not Encryption, A Common Security Mistake

Base64 offers zero security. The encoding is fully reversible by anyone in milliseconds, the alphabet is public, the algorithm is trivial, and any browser or one-line CLI command can decode it. Despite this, "Base64-encoded sensitive data" is one of the most-cited examples in MITRE's CWE-261 (Weak Encoding for Password) and shows up in security audits constantly: API keys "obfuscated" by Base64 in client code; passwords "encoded" with Base64 in database backup files; secrets "encrypted" with Base64 before being committed to a public Git repository. None of these are protected. If you need actual confidentiality, use real encryption: AES-256-GCM for symmetric, RSA-OAEP or ECDH+ChaCha20-Poly1305 for asymmetric. Base64 is appropriate for transport (turning binary into a text-friendly form) but never for protection.

Browser Implementation: btoa / atob and the Unicode Pitfall

JavaScript exposes two built-in global functions for Base64: btoa() (binary-to-ASCII, encode) and atob() (ASCII-to-binary, decode). Both are legacy APIs from the early Netscape era and have a famous limitation: they only work on Latin-1 byte strings. Calling btoa('é') throws InvalidCharacterError because the JavaScript string 'é' contains a code point above U+00FF that doesn't fit in a single byte. The modern fix is to encode to UTF-8 bytes first via TextEncoder, then convert the resulting Uint8Array to a Latin-1 string for btoa() consumption. The pattern: btoa(String.fromCharCode(...new TextEncoder().encode(str))). Decoding the reverse: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Newer browsers expose Uint8Array.toBase64() and Uint8Array.fromBase64() as built-in methods, but adoption is still rolling out as of 2026, the polyfill via btoa/atob remains the cross-browser default. For files specifically, FileReader.readAsDataURL() is the simplest path: drop a file into an input, the reader returns a data:mime/type;base64,... string with everything correctly encoded; strip the data: prefix to get just the Base64 portion.

Honest Scope: What This Tool Does and Doesn't

This tool encodes text or files (up to 5 MB) to Base64 and decodes Base64 strings back to text or downloadable files. It uses the standard RFC 4648 alphabet (with + and /) by default; URL-safe Base64URL (with - and _) is a future-feature toggle. UTF-8 text is handled correctly via TextEncoder: the btoa-Latin-1 pitfall is fixed. The 5 MB file size cap exists because Base64 expands data by 33% and the encoded string lives entirely in browser memory; a 5 MB binary file produces ~6.7 MB of Base64 text plus the original buffer, which works on every modern device. For larger files, the standard alternatives are command-line base64 on macOS/Linux (base64 -i input.bin -o output.txt), Python's base64 module, or Node.js Buffer.from(data).toString('base64'). This tool does not handle: streaming Base64 (file-by-chunk encoding for files larger than memory); the URL-safe variant in this version (planned); nor MIME quoted-printable encoding (a different RFC 2045 scheme for text email content).

Privacy: Why Browser-Only Matters

Base64 is not encryption, but the data being encoded is often sensitive: API keys you're embedding in a config file, certificates you're encoding for transport, internal screenshots you're embedding as data URIs in documentation, or PDF receipts you're encoding for a client. Server-side encoders see your input. This tool runs entirely in your browser via JavaScript, verify in DevTools' Network tab while you click Encode, or take the page offline (airplane mode) after it loads and the tool still works. Safe for encoding API credentials, PII screenshots, internal documents or any data you wouldn't want copied onto a stranger's hard drive.

Frequently Asked Questions

Is Base64 secure?

No, Base64 is encoding, not encryption. The alphabet and algorithm are public; anyone can decode a Base64 string in milliseconds with a CLI tool, browser console, or this very page. MITRE's CWE-261 specifically lists Base64 as a weak encoding for passwords. Never use Base64 to "obfuscate" sensitive data, for actual confidentiality, use AES-256-GCM (symmetric) or RSA-OAEP / ECDH+ChaCha20-Poly1305 (asymmetric).

Why does Base64 make data ~33% larger?

Each three bytes of binary input (24 bits) become four Base64 characters (each carrying 6 bits = 4 × 6 = 24 bits). Four characters representing three bytes is exactly 4/3 = 133% of the original size. Add padding for inputs whose length isn't a multiple of three, and the average sits just over 33% expansion. This is the cost of being able to transmit binary data through 7-bit-clean text channels, for cases where the channel can carry binary directly, no encoding is needed.

Can I encode files?

Yes. Drag and drop any file (up to 5 MB) onto the file zone, or click to browse. The file is read via FileReader.readAsDataURL() and converted to a Base64 data URI of the form data:mime/type;base64,... that you can paste directly into HTML, CSS, or JavaScript. For files larger than 5 MB, use a command-line tool: base64 on macOS/Linux, Python's base64 module, or Node.js Buffer.from(data).toString('base64').

What's the difference between Base64 and Base64URL?

Two characters. Standard Base64 (RFC 4648 §4) uses + and / as the 62nd and 63rd alphabet characters. URL-safe Base64URL (RFC 4648 §5) uses - and _ instead, so the encoded string drops directly into URLs without percent-encoding. JWT, OAuth, WebAuthn and most modern web APIs use Base64URL. This tool currently emits standard Base64; URL-safe is on the future-feature list. To convert standard to URL-safe by hand: replace + with -, / with _, optionally drop trailing = padding.

Why does my Unicode text fail in some Base64 tools?

Because JavaScript's legacy btoa() function only works on Latin-1 byte strings, calling btoa('é') throws InvalidCharacterError. Many old browser-based encoders use btoa directly without the UTF-8 conversion step, so any non-ASCII input breaks. Modern code (and this tool) encodes strings via TextEncoder first, producing a UTF-8 byte sequence that btoa can then encode safely. The newer Uint8Array.toBase64() built-in method handles UTF-8 natively but isn't yet baseline across all browsers.

Are my data uploaded?

No. Encoding and decoding run entirely in your browser via JavaScript. Text and files never cross the network, verify in DevTools' Network tab while you click Encode, or take the page offline (airplane mode) after it loads and the tool still works. Safe for API credentials, PII-bearing screenshots, internal config files or any data you wouldn't want copied onto a stranger's hard drive.

Related Tools