🔁 Base64 Encoder / Decoder

What Is Base64 and Why Does It Exist?

Every programmer eventually hits a moment where they need to move binary data through a channel that was designed only for text. Email attachments, JSON payloads, HTTP headers, environment variables — all of these are text-first environments that choke on raw bytes containing control characters or values above 127. Base64 was invented precisely to solve this friction.

The algorithm maps every three bytes of binary input into four printable ASCII characters drawn from a 64-character alphabet: the 26 uppercase letters A–Z, 26 lowercase letters a–z, the digits 0–9, and the two symbols + and /. A = sign is appended as padding when the input length is not a multiple of three. The result is always safe to copy, paste, store, and transmit anywhere text is accepted.

That 33 % size overhead (every 3 bytes becomes 4 characters) is the deliberate trade-off Base64 makes. For the use cases it targets — embedding small certificates, tokens, and keys — that overhead is entirely acceptable.

Standard Base64 vs URL-Safe Base64

The standard RFC 4648 alphabet contains + and /. Both of those characters carry special meaning inside URLs: + represents a space in query strings, and / is a path separator. If you embed a standard Base64 string directly in a URL without percent-encoding it, the server may misinterpret the value entirely.

The URL-safe variant (RFC 4648 §5) replaces + with - and / with _. That is the only change. The resulting string can be placed in a URL path or query parameter without any further encoding. This variant is used everywhere tokens travel through URLs: OAuth 2.0 access tokens, JSON Web Tokens (JWTs), signed cookies, Google Cloud Storage object names, and many API authentication headers.

When decoding, you must know which variant was used, because - and _ are not valid in standard Base64 and will cause a decoding error if you do not convert them back first.

Where You Will Actually Use Base64

Encryption keys and secrets. Raw AES, RSA, or Ed25519 key material is binary. Storing it in a config file or environment variable requires encoding. The patterns SOME_SECRET=<base64> in a .env file and PEM-formatted certificates (which are Base64-wrapped DER data between -----BEGIN CERTIFICATE----- markers) both rely on this encoding.

JWTs. A JSON Web Token has three sections — header, payload, and signature — each individually Base64url-encoded and joined with dots. Decoding the middle section in this tool instantly reveals the claims the server embedded: user ID, expiry, roles, and any custom fields. No secret is needed to read the header and payload; the signature is what proves they haven't been tampered with.

Data URIs. Browsers accept images, fonts, and other assets inlined directly in HTML or CSS as data:image/png;base64,.... Encoding a small icon and inlining it eliminates one HTTP round trip.

API payloads. Any REST API that accepts binary content — a PDF to OCR, an image to classify, a voice clip to transcribe — almost always asks for the file as a Base64 string inside a JSON field rather than a multipart upload.

How to Use This Tool

Encoding text. Type or paste your text into the input area. Choose Standard or URL-Safe from the variant dropdown depending on where the result is going. If you need MIME-compatible line wrapping (required by some email systems), check "Add line breaks every 76 chars." If your target system handles Base64 without padding, check "Omit padding." Click Encode to Base64. The result appears instantly in the output area with character counts and a size ratio so you can see the overhead at a glance.

Encoding a file. Click Upload File. The tool reads the file as raw bytes using the browser's FileReader API, converts the byte array to Base64, and displays the result. This works for any file type — images, PDFs, ZIPs, binaries. Nothing is uploaded to any server; the conversion happens entirely in your browser tab.

Decoding text. Paste your Base64 string into the input area. The tool normalises the input automatically: it strips whitespace, converts URL-safe characters to standard ones, and restores missing padding before calling the browser's built-in atob() function. If the result decodes cleanly to valid UTF-8, it is shown as text. If the bytes are not valid UTF-8 (a binary file, an encrypted blob), the tool shows a hex dump instead and offers a binary download button so you can save the decoded bytes as a file.

Copying and downloading. The Copy button writes the output to your clipboard. The Download button saves the output as a .txt file, or as a binary .bin file when binary data was decoded.

Common Pitfalls and How to Avoid Them

Wrong variant. If you decode a URL-safe token with a standard decoder, the - and _ characters will cause an error or silently corrupt the output. This tool converts both automatically before decoding, so you do not need to worry which variant was used — paste it in and click Decode.

Padding errors. Some systems strip trailing = signs to shorten tokens. A standard decoder will reject the string because the length is not a multiple of four. This tool adds back the necessary padding characters before decoding, so stripped-padding strings work out of the box.

Encoding text vs encoding bytes. If you type text containing characters above ASCII 127 — accented letters, emoji, Chinese characters — and encode it naively, different tools may produce different results because the bytes they feed into Base64 depend on the character encoding they assume. This tool always encodes text as UTF-8 first, then Base64-encodes the resulting bytes. This matches the behaviour expected by virtually every modern system.

Base64 is not encryption. Base64 is reversible by anyone with a decoder. It provides zero confidentiality. It is not a substitute for encryption, hashing, or any other security mechanism. When you need to protect data, encrypt it with AES-GCM or similar and then Base64-encode the ciphertext for transport — never rely on Base64 alone to hide sensitive information.

Tips for Working With Specific Formats

To decode a JWT, paste the full token and split it at the dots yourself, then decode the second segment (the payload). You will see the JSON claims as plain text. The third segment (signature) will decode to binary — that is expected.

To inspect a PEM certificate, strip the header/footer lines (-----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----), concatenate the remaining lines, and paste into the decode field. The output will be binary DER data. While this tool shows it as hex, you would normally pipe DER into openssl x509 -inform der -text for a human-readable breakdown.

For environment variables holding Base64 secrets, avoid line breaks in the encoded value. Leave the MIME line-break option unchecked to get a single uninterrupted string that shell parsers will not accidentally split.