Base64 Encoder and Decoder

Introduction:

Bytes do not always survive when they are moved through systems that expect plain text. A byte may contain a control value, part of an image, a compressed archive, a certificate, or a text character from a specific character set. Base64 gives those bytes a printable spelling, so the data can pass through text fields, configuration files, email bodies, JSON values, logs, and URLs without being changed by line endings or character conversion.

The idea is mechanical rather than secret. Base64 groups input bits, looks up printable symbols, and writes text that can later be decoded back to the same bytes. The encoded text is usually larger than the original data and is not meant to be readable by people. Its value is compatibility: it lets binary material sit in places that would otherwise reject or damage raw bytes.

Several spellings can decode to the same bytes. Padding signs can be present or omitted when the data length is known from context. Long strings can be wrapped across lines for mail or certificate formats. The URL-safe alphabet changes only two symbols, but those two symbols matter when a value is placed in a path, query value, filename, or token.

Text adds one more layer of choice before Base64 begins. UTF-8, UTF-16LE, Latin-1, and ASCII can turn the same visible character into different byte values, so the encoded output changes even though the text looks similar. On decode, unreadable output does not always mean the Base64 is wrong; the recovered bytes may be binary data, compressed data, encrypted data, or text interpreted with the wrong character encoding.

Base64 is not encryption, compression, authentication, or malware scanning. It is reversible encoding. A token, password, private key, document, or image remains sensitive after it has been converted into printable text.

How to Use This Tool:

Choose the direction first, then match the format options to the system that will receive the encoded or decoded value.

1. Select Encode when plain text or a file needs a Base64 representation. Select Decode when the main field already contains Base64, base64url, or a Base64 Data URL.
2. Paste into Text to encode or Base64 to decode, or use Browse file. In encode mode, file input preserves the original bytes; in decode mode, a selected file is read as a text payload.
3. Set Text encoding for typed text before encoding. For decode mode, choose Decoded output as UTF-8, UTF-16LE, Latin-1, ASCII, or Raw bytes preview when the content may not be readable text.
4. Turn on URL-safe alphabet when the encoded value is headed for a URL, filename, or token field. Decode mode accepts both standard and URL-safe symbols, so this setting is mainly a format choice for new encoded output.
5. Open Advanced for Include padding on encode, Fix missing padding on decode, Line wrapping, Line ending, and Data URL output. Use PEM 64, MIME 76, or a custom wrap count only when the destination expects fixed columns.
6. Use Strip non-Base64 characters only for copied punctuation, whitespace, brackets, or separators. Remove alphabetic labels such as token= manually because letters are valid Base64 characters and can become part of the attempted decode.
7. Read the main result tab first, then confirm Payload Fields for mode, byte counts, alphabet, padding, and wrapping. Use Byte Breakdown when the decoded output is binary, uses control bytes, or displays unexpected replacement characters.

Interpreting Results:

The first result tab is the value most people need to copy. In encode mode it shows Encoded Base64, or Data URL Text when Data URL output is enabled. In decode mode it shows Decoded Text or Decoded Byte Preview according to the selected output encoding.

Payload Fields explains why two outputs differ. Padding, line wrapping, URL-safe symbols, and a Data URL prefix can change the visible text without changing the decoded bytes. Byte Breakdown is the stronger check when exact byte values matter because it lists each byte by index, hexadecimal value, decimal value, and printable character when one exists.

A successful decode means the input was parseable as Base64 after the selected cleanup and padding choices. It does not prove that the recovered data is safe, trusted, unencrypted, uncompressed, or valid for the application that will consume it. If Invalid Base64 input appears, remove wrapper words first, then compare strict validation with padding repair before deciding that the payload is corrupted.

Technical Details:

Base64 operates on octets. Text must be encoded into bytes first, while selected files already provide bytes. The byte stream is split into 24-bit groups, each full group is divided into four six-bit indexes, and each index selects one symbol from a 64-character alphabet.

Short final groups are handled with zero bits for lookup and optional = padding in the displayed text. Padding is not part of the original data. It marks how many bytes were missing from the final three-byte group so a decoder can recover the original byte count without guessing.

Formula Core

For N input bytes, padded length is computed before line wrapping, Data URL prefixes, or URL-safe symbol replacement. Unpadded output removes only the trailing padding signs.

Five input bytes produce two four-character groups, so the padded output length is eight characters. Since 5 mod 3 = 2, the final group uses one padding sign and an unpadded variant displays seven Base64 characters.

Transformation Core

Decode Cleanup and Failure Cases

Whitespace is removed before validation. URL-safe symbols are normalized to the standard alphabet before decoding, so either alphabet can be read. Padding repair can append missing trailing = signs when the length suggests they were omitted, but it cannot repair every malformed value.

Privacy Notes:

The built-in text and file conversion workflow runs in the browser, so selected files are not uploaded to a conversion service for encoding or decoding. The browser still handles the material you enter: output can be copied to the clipboard, downloaded, opened as a Data URL, or preserved in page state for later restoration.

• Do not share a page link while sensitive pasted values remain in fields that may be restored from the URL.
• Treat decoded credentials, tokens, certificates, and private files as sensitive even when they look like ordinary text.
• Use file input for binary data so a text editor does not change bytes before encoding.

Worked Examples:

Encoding a short UTF-8 value

With Encode, Text encoding set to UTF-8, and the text Hello, the Encoded Base64 tab shows SGVsbG8=. Payload Fields reports 5 input bytes and 8 output bytes because padded Base64 writes four characters for each three-byte group.

Preparing a URL token

Encoding user:42 with URL-safe alphabet on and Include padding on encode off produces dXNlcjo0Mg. Payload Fields should show the URL-safe alphabet and padding removed, which matches token formats that do not want trailing = signs.

Reading a complete Data URL

In Decode mode, pasting data:text/plain;base64,SGVsbG8= recovers Hello in Decoded Text. The same payload can be inspected in Byte Breakdown, where the recovered bytes are 48, 65, 6c, 6c, and 6f in hexadecimal.

Fixing a copied wrapper

A log value such as token=SGVsbG8= may fail or decode to the wrong bytes because token contains valid Base64 letters. Delete the label and keep only SGVsbG8=; use Strip non-Base64 characters only for punctuation or separators that are not part of the alphabet.

FAQ:

Glossary:

Octet

An eight-bit byte, the unit Base64 encodes and decodes.

Base64 alphabet

The 64 printable characters used to spell six-bit values.

Padding

Trailing = signs that describe a short final byte group.

base64url

The URL and filename-safe variant that uses - and _.

Data URL

A data: address that carries a media type and inline payload.

Byte preview

A readable view of recovered bytes where printable characters are shown and non-printable bytes are marked.

References:

• RFC 4648: The Base16, Base32, and Base64 Data Encodings, RFC Editor, October 2006.
• RFC 2397: The "data" URL scheme, RFC Editor, August 1998.
• data: URLs, MDN Web Docs.