Base64 Encode Decode

Base64 is a text-encoding scheme. It converts arbitrary bytes into 64 printable ASCII characters (A–Z, a–z, 0–9, +, /) so that binary data can be safely embedded in text-only contexts: HTTP headers, JSON values, email bodies, HTML attributes, and CSS data URIs.

It is not encryption, not hashing, and not obfuscation. Anyone who sees a Base64 string can decode it in seconds with any decoder — including this one. It provides zero confidentiality.

Do not use Base64 to "hide" passwords, API keys, or any sensitive value. If a credential is encoded in Base64 inside a config file or a request header, it is readable by anyone who intercepts that header or reads that file.

Base64 encodes 3 bytes of input into 4 output characters, working in 3-byte blocks. Each group of 6 bits maps to one character from the 64-character alphabet.

When the input byte count is not a multiple of 3, one or two = padding characters are appended so the output length is always a multiple of 4. One = means 1 byte of padding was added; == means 2 bytes.

The padding characters carry no data — they are structural markers. Some implementations (especially URL-safe Base64 used in JWTs) omit them entirely. If you get a decode error on a string without padding, try appending = or == until the length is a multiple of 4.

HTTP Basic Authentication encodes credentials as Base64 in the Authorization header. The format is: Authorization: Basic <base64(username:password)>.

To inspect credentials from a captured header: take the value after "Basic ", paste it into the decode field here, and read the username:password in plain text. This is exactly why Basic Auth must only be used over HTTPS — the "encoding" provides no protection at all.

Bearer tokens and API keys in Authorization headers are not Base64-encoded — they are opaque strings passed as-is. Only the Basic scheme uses Base64.

Standard Base64 uses + as character 62 and / as character 63. Both have special meaning in URLs: + is interpreted as a space in form encoding, and / is a URL path separator. Embedding standard Base64 in a URL requires percent-encoding those characters.

Base64URL solves this by substituting - for + and _ for /. Padding (= signs) is also typically omitted because = is reserved in query strings. This variant is used in JWTs, OAuth tokens, and any context where the encoded value appears in a URL.

JWT segments — the header and payload — are Base64URL-encoded, not standard Base64. If you try to decode a JWT segment with a standard decoder and get garbage or an error, that is why. Either replace - with + and _ with / manually, or use the JWT Decoder tool which handles the conversion automatically.

API responses — some APIs return binary content (PDFs, images, cryptographic signatures) as Base64 inside a JSON field. Decode the field value here to inspect the raw content as text, or save it as bytes.

Configuration files — service account JSON keys (Google Cloud), SSH private keys, and TLS certificates are often Base64-encoded when embedded in environment variables or YAML config.

Email — MIME encoding uses Base64 to represent attachments and non-ASCII body content. If you are inspecting a raw email message, the encoded blocks are Base64.

Data URIs — img src="data:image/png;base64,…" and similar CSS background values embed file content inline. The portion after the comma is standard Base64.

Wrong variant: the input is Base64URL (uses - and _) but you are using a standard decoder. Replace - with + and _ with /, then try again.

Missing padding: URL-safe Base64 strips trailing = signs. If the encoded string length is not a multiple of 4, add one or two = characters at the end.

Binary content: decoding a Base64-encoded image, PDF, or other binary file as UTF-8 text will always produce garbled output — the underlying bytes are not valid text. This is expected; use a binary-aware tool or save the bytes directly.

Whitespace and line breaks: some encoders wrap output at 76 characters (MIME standard). Remove all newlines and spaces before decoding.

In Node.js, use the Buffer API — it handles UTF-8 correctly and avoids the Latin-1 restriction of the browser's built-in btoa/atob.

In Python, use the base64 standard library. In the browser, btoa and atob are natively available but only handle ASCII and Latin-1 characters correctly; for Unicode text, encode through TextEncoder first.

On the command line, base64 (Linux/macOS) or certutil (Windows) encode files or strings. Useful when you need to Base64-encode a file for an API request or environment variable.