Base64 Encoder and Decoder

Introduction:

Base64 is a transport format for bytes. It exists because many systems are comfortable with printable text but not with raw binary data, so files, tokens, message parts, and inline assets are often rewritten as characters before they move through forms, APIs, email bodies, or config fields. The practical question is usually not whether the string looks readable, but whether it still represents the exact bytes you started with.

That is where confusion starts. The same payload can appear with or without trailing = signs, with -_ instead of +/, or with hard line wraps every 64 or 76 characters. A decoded result can also look wrong even when the bytes are correct, simply because those bytes are being read as the wrong character encoding.

Those variants do not always mean the payload changed. Standard Base64 and URL-safe Base64 carry the same 6-bit values with different symbols for two alphabet positions. Padding may be omitted when the data length is already known. MIME and certificate-style text formats may insert fixed line breaks even though the underlying bytes stay the same.

Data URLs add one more layer by placing Base64 after a media-type prefix such as data:image/png;base64,. That lets a browser treat the string as inline content, which is useful for small embedded assets and quick previews, but it also makes it easy to confuse the wrapper text with the payload itself.

None of this provides secrecy. Base64 is reversible encoding, not encryption, hashing, or signing. If the original bytes were sensitive, the encoded text still deserves the same care as the source file, token, or message body.

Technical Details:

Base64 operates on bytes in groups of 24 bits. Three 8-bit bytes are concatenated, split into four 6-bit values, and then mapped to a 64-character alphabet. In the standard form that alphabet uses A-Z, a-z, 0-9, +, and /. The trailing = sign is not part of the 64-value lookup table. It is a padding marker used only when the final input group is shorter than three bytes.

That structure explains both the familiar size increase and the tail behavior. Encoded output is usually about one third larger than the original byte stream before line wrapping or Data URL prefixes are added. The padded output length and padding count for N input bytes can be written as follows.

If one byte is left over, the encoded tail contains two data characters and two = signs. If two bytes are left over, the tail contains three data characters and one =. Unpadded forms remove those visible markers, but the recovered bytes can still be identical when the decoder restores the missing length information correctly.

Transformation Core

Text introduces an earlier stage that raw files do not. Characters must first be encoded into bytes, and that choice can change the Base64 result even when the visible text looks the same. UTF-8, UTF-16LE, Latin-1, and ASCII do not produce the same byte stream for many real-world strings. A file upload skips that character-to-byte step because it already starts as bytes. Decoding reverses the process: Base64 text becomes bytes first, and only then can those bytes be shown as text or inspected as raw values.

Variant rules change presentation around that core mapping. URL-safe Base64 replaces + and / with - and _. MIME transport commonly wraps lines at 76 characters. PKIX and PEM-style textual encodings commonly use 64-character lines. Data URLs place a media type and ;base64, marker in front of the payload without changing the Base64 body that follows.

Everyday Use & Decision Guide:

Start with the source, not the output. Choose Encode when you have text or a file and need a Base64 string. Choose Decode when you already have Base64 text and need to inspect what it contains. If the source is a binary file, upload or drag the file instead of pasting into a text box. That keeps the original bytes intact and, in encode mode, can also fill the MIME field for Data URL work.

For ordinary text, UTF-8 is the right first pass. Change the text encoding only when you know the destination expects UTF-16LE, Latin-1, or ASCII. If two systems produce different Base64 from the same visible sentence, the mismatch is often in the text-to-byte step rather than in Base64 itself. Accents, emoji, and non-Latin scripts are the quickest way to expose that difference.

Decode mode is easiest to trust when you stay conservative at first. Leave Fix missing padding on, because URL tokens and copied fragments often omit trailing = characters. Leave Strip non-Base64 off until you know the pasted block contains wrappers, separators, or mail-style noise that should be ignored. If the result looks garbled, switch Output as to another text encoding or to Raw bytes only, then inspect Byte Breakdown before copying anything forward.

• Primary output is for quick copy or download of the current visible surface.
• Byte Breakdown is the exact inspection view, with index, hex, decimal, and printable-character columns plus CSV and DOCX export.
• Data URL appears in encode mode when the wrapper is enabled, which is useful for small inline browser assets.
• JSON records the current settings, byte totals, and a short preview so the same check can be repeated later.

A clean decode does not mean the content is safe or even meant to be read as text. Before reusing the result in another system, compare the summary badges, byte counts, and Byte Breakdown with what that system actually expects.

Step-by-Step Guide:

1. Choose Encode for source text or files, or choose Decode for an existing Base64 string.
2. Paste the source text, paste the Base64 payload, or upload a file. For binary content, prefer the file input so the original bytes stay intact.
3. If you are encoding text, keep UTF-8 unless you know another text encoding is required. If you are decoding, choose whether the recovered bytes should be shown as text or as a raw-byte preview.
4. Adjust variant settings only when the destination requires them: URL-safe alphabet, padding policy, wrap width, newline style, or Data URL output.
5. If decode errors appear, keep padding repair on first and enable Strip non-Base64 only when the source clearly contains wrapper text or separators.
6. Read the summary badges, confirm the main output, and open Byte Breakdown or JSON before copying or downloading the final result.

Interpreting Results:

The summary badges are the fastest sanity check. Mode confirms direction. In and Out show source and result sizes, but they mean different things in each mode. When encoding, input bytes are the raw text or file bytes and output size reflects the emitted Base64 text or Data URL length. When decoding, input size reflects the pasted string length and output bytes reflect the recovered payload length.

The main output pane always shows the current display surface. In text decode mode, that surface is decoded text. In Raw bytes only mode, it is a printable preview rather than a full hex dump, so exact verification belongs in Byte Breakdown. If the hex and decimal columns look plausible but the character column shows many dots, the payload is probably binary or is being read with the wrong text encoding.

Error messages are literal. Found non-Base64 characters. Enable "Strip non-Base64" in Advanced to ignore them. means disallowed characters remain after the current cleanup rules. Invalid Base64 content. means the cleaned string still cannot be decoded into a valid byte stream. In both cases, compare the pasted source with the URL-safe, padding, and strip settings before assuming the payload itself is broken.

The JSON pane is useful when you need to repeat a check later. It stores the mode, encoding choices, wrap policy, padding settings, MIME value, byte totals, and a short preview of the current result.

Worked Examples:

Comparing text that contains non-ASCII characters

A short phrase with accented letters or emoji can produce different Base64 depending on whether the sender treated it as UTF-8, UTF-16LE, or a single-byte encoding. In encode mode, keep the text the same and switch only the text encoding. If the summary byte counts and Byte Breakdown rows change, the difference comes from the text-to-byte step, not from Base64 padding or URL-safe symbols.

Cleaning a wrapped certificate or mail-style block

A pasted certificate fragment or MIME body often arrives with fixed line wraps and may include wrapper lines or copied commentary. Start decode mode with padding repair on and stripping off. If the block still fails because of non-Base64 characters, enable Strip non-Base64 only after you confirm the extra text is not part of the payload. Then compare the recovered byte count and printable preview with the type of file you expected to see.

Making a small file usable as an inline browser asset

Upload a small image in encode mode, let the MIME field auto-fill if the browser provides it, and enable Data URL. The Data URL tab then gives you a string that begins with data:<type>;base64, and can be copied into markup or CSS. If the result becomes too long to manage comfortably, keep the plain Base64 output instead and let the destination system handle the file separately.

FAQ:

Glossary:

Byte

An 8-bit unit of data. Base64 converts bytes into printable text characters.

Padding

One or two trailing = signs used to mark a short final Base64 group in the standard padded form.

URL-safe Base64

A Base64 variant that uses - and _ instead of + and /.

Data URL

A string that combines a media type and inline content in the form data:<type>;base64,<payload>.

Character encoding

The rule that turns text into bytes and bytes back into text, such as UTF-8 or UTF-16LE.

MIME wrap

A transport convention that breaks Base64 text into fixed-width lines, commonly 76 characters.

References:

• RFC 4648: The Base16, Base32, and Base64 Data Encodings, RFC Editor, October 2006.
• RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC Editor, November 1996.
• RFC 2397: The "data" URL scheme, RFC Editor, August 1998.
• RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures, RFC Editor, April 2015.