Base64 Encoder/Decoder

How it works

What Base64 encoding is for

Base64 encode and decode operations solve one narrow problem: moving binary data through a channel that only reliably carries text. It represents arbitrary bytes using 64 printable ASCII characters — A-Z, a-z, 0-9, + and / — with = as padding, as defined in RFC 4648.

Three bytes of input become four output characters. When the input is not a multiple of three, the last group is padded with = so the output length is always divisible by four.

The size cost

Because every three bytes become four characters, Base64 output is roughly one third larger than its input:

The overhead converges toward 33% as input grows; short inputs pay more because of padding. This is why Base64 is a poor choice for large payloads — inlining a 2 MB image as a data URI ships roughly 2.7 MB of text.

Where it is genuinely the right tool

• Data URIs. Embedding a small icon or font directly in CSS or HTML, avoiding a network request.
• Basic authentication headers. Authorization: Basic carries base64-encoded credentials.
• Binary inside JSON or XML. Neither format can carry raw bytes, so binary fields are conventionally base64.
• Email attachments. MIME has used Base64 for binary parts since long before the web.
• JWTs. Each segment of a JSON Web Token is base64url-encoded.

Base64 is not encryption

This is the single most important thing to understand about it, and the most commonly confused. Base64 is a reversible encoding with no key. Anyone who sees the string can decode it in one step — including with this page.

That has real consequences:

• A password hidden with Base64 in a config file is stored in plain text with extra steps.
• Credentials in a Basic auth header are protected by TLS in transit, not by the encoding.
• Base64 in a URL or log line should be treated as fully visible.

If you need confidentiality, you need actual encryption. Base64 only makes bytes safe to transport, never safe to expose.

Base64 and base64url

There is a second variant worth knowing. Standard Base64 uses + and /, both of which have special meaning in URLs. The base64url variant substitutes - and _ and usually drops the padding, which is what JWTs and many APIs use. This decoder accepts either alphabet. If decoded bytes are not UTF-8 text, use the binary download rather than treating them as corrupted text.

Everything here runs in your browser. Nothing you paste is uploaded, logged or stored, so encoding a credential to check a header is safe from this page's side.

Encoding reference

RFC 4648 defines Base64 and its URL-safe alphabet. This tool accepts whitespace and optional padding as a convenience; stricter receiving systems may require canonical padding.

Worked examples: bytes, Unicode and binary output

The example buttons above load synthetic data with predictable answers. Use these to distinguish an encoding problem from a display problem before working on your own payload.

Why character count and byte count disagree

For standard padded output, the encoded length is 4 × ceil(byte count / 3). The relevant input size is UTF-8 bytes, not the character count shown by a text editor. Hello uses five bytes and produces eight Base64 characters. The check mark ✓ uses three bytes and produces four. URL-safe output omits padding here, so its length can be shorter. A data URI adds a prefix on top of the encoded payload.

The tool’s length cards count JavaScript string characters; they do not measure file size or UTF-8 bytes. The “about one third larger” rule applies to the encoded representation of sufficiently long byte sequences, not to every short input or visible-character count.

Recover a file without converting its bytes to text

Choose Decode and paste a Base64 payload or Base64 data URI. If the decoded bytes are invalid UTF-8 or contain non-text control bytes, the page displays a binary summary and offers a download of the original bytes. For the -_8= example, the download contains exactly two bytes, hexadecimal FB FF. Copying the summary text does not recover those bytes; use the binary download.

Some files contain only readable UTF-8 and therefore appear as text. MIME detection uses a few image signatures, not a full file validator. An inferred PNG or JPEG label does not establish that the complete file is valid. Keep the source file extension and expected format when diagnosing a payload.

Diagnose a decoding failure

• Check whether you pasted JSON quotes, a Bearer prefix or other surrounding text along with the payload.
• If the value came from a form-encoded query, check whether a + became a space. This decoder removes whitespace, so it cannot reconstruct a lost plus sign for you. Recover the original value at the source.
• A single-character final group is incomplete. A cannot represent a complete byte; adding arbitrary padding does not repair missing data.
• Valid Base64 can still contain the wrong data. Decoding does not verify a checksum, identify a trusted source or establish a file’s safety.

For a JWT, use JWT Decoder: a whole dot-separated token is not one Base64 payload. For JSON text recovered from Base64, JSON Formatter can check syntax. These are separate steps; a successful decode alone does not validate the application data.

FAQ