{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}

Base64 source and conversion controls
Auto reports the resolved direction; a pinned operation bypasses detection.
{{ sourceHelp }}
{{ sourceMeta }}
{{ sourceActionHint }}
UTF-8 fits normal web text; pin a legacy mapping only when the source bytes require it.
Choose Base64URL when the result will be carried in a URL, filename, or token field.
Choose byte preview when the decoded payload is binary or its character set is unknown.
{{ workflowFeedback }}
{{ handoffStatus }}
The default preserves RFC 4648 padding; this refinement removes only trailing equals signs.
{{ params.omit_padding ? 'Enabled' : 'Disabled' }}
Keep off for strict input; turn on for intentionally unpadded Base64URL or copied tokens.
{{ params.repair_padding ? 'Enabled' : 'Disabled' }}
Leave off for validation; enable only when separators outside both Base64 alphabets are known wrappers.
{{ params.ignore_non_alphabet ? 'Enabled' : 'Disabled' }}
No wrap is best for tokens; use a fixed width only when the receiving format expects it.
This changes inserted wrapping characters only.
The default emits only Base64. Enable the envelope when the downstream consumer expects a complete data URL.
{{ params.data_url ? 'Enabled' : 'Disabled' }}
{{ primaryOutput }}
SignalValueMeaningCopy
{{ row.signal }}{{ row.value }}{{ row.detail }}
OffsetHexDecimalCharacterCopy
{{ row.offset }}{{ row.hex }}{{ row.decimal }}{{ row.character }}
The current payload has zero bytes.

Introduction:

Many text-based systems cannot carry arbitrary bytes safely. An image, archive, certificate, or control character may be changed or rejected when it passes through a text field. Base64 solves that transport problem by spelling binary data with a small set of printable characters.

The result is encoding, not secrecy. Anyone can reverse a Base64 string without a password, and the encoded form is usually larger than the original bytes. Its advantage is compatibility with places such as JSON strings, email bodies, configuration values, URL tokens, and inline browser data.

Bytes
The exact binary values that Base64 preserves. Text must first be turned into bytes with a character encoding such as UTF-8.
Alphabet
Standard Base64 uses + and /. Base64URL replaces them with - and _ for URL and filename contexts.
Padding
One or two trailing = signs complete the final four-character group when the byte count is not divisible by three.

Two Base64 strings can look different and still represent the same bytes. Line wrapping changes presentation, URL-safe symbols change the alphabet, and some formats omit padding. A Data URL adds a media-type prefix around the Base64 payload so a browser can interpret the decoded bytes.

Character encoding matters before and after Base64. The same visible text can produce different bytes in UTF-8, UTF-16LE, Latin-1, or ASCII. Likewise, a valid decoded payload may appear unreadable because it is binary data or because the wrong text encoding was chosen.

A successful decode proves only that the selected parsing rules accepted the string. It does not prove that the content is safe, authentic, uncompressed, or correctly labeled.

How to Use This Tool:

Pin the direction when you know it. Use automatic detection only when the source may be either ordinary text or a Base64 payload.

  1. Choose Encode source for text or raw file bytes, or Decode Base64 or Data URL for an existing encoded value. Automatic detection treats ambiguous Base64-shaped text as text rather than decoding it.
  2. Paste text or browse for one file. Encode mode can read raw file bytes; decode mode needs a readable text file containing Base64 or a Data URL. For uncertain decoded content, select Raw byte preview.
  3. Select Standard Base64 or Base64URL for new encoded output. Keep padding and no wrapping unless the receiving format specifically calls for unpadded or fixed-width text.
  4. Enable Padding repair only for intentionally unpadded input. Enable Lenient cleanup only when known separators surround the payload; alphabetic wrapper text must be removed manually because letters are valid Base64 symbols.
  5. Check Converted text first, then use Payload audit and Byte ledger to confirm the resolved direction, alphabet, byte count, and recovered byte values.

Interpreting Results:

For encoding, the main output is transport text. Padding, line breaks, a URL-safe alphabet, or a Data URL prefix can change that text without changing its underlying payload. Compare Payload bytes rather than visible length when checking whether two forms carry the same data.

For decoding, inspect the byte ledger when text contains replacement characters, control characters, or unexpected symbols. Strict UTF-8 failure can mean the bytes use another character set or are not text at all.

Padding repair cannot restore missing data. A Base64 length whose remainder is one after division by four indicates a truncated or malformed payload, and non-zero unused tail bits also make the encoding invalid.

Technical Details:

Base64 processes bytes in groups of three. Each 24-bit group becomes four 6-bit indexes, and each index selects one character from a 64-symbol alphabet. Decoding reverses that mapping and discards only the zero bits implied by valid padding.

Formula Core

For N input bytes, padded Base64 length is four times the number of three-byte groups, including a final partial group.

Lpadded = 4 × ⌈N3⌉

Five bytes therefore produce eight padded characters. Two leftover bytes need one padding sign, so the corresponding unpadded form contains seven characters.

Transformation Core

The word cat is a complete three-byte example, so no padding is needed.

Base64 transformation of the UTF-8 text cat
Stage Value Meaning
UTF-8 bytes 63 61 74 Three hexadecimal byte values.
Six-bit groups 011000 110110 000101 110100 Four indexes from 0 to 63.
Alphabet lookup Y2F0 The printable Base64 representation.
Base64 variants and validation rules
Rule Exact behavior Consequence
Whitespace Removed before decode validation. Wrapped payloads recover the same bytes.
URL-safe symbols - maps to +; _ maps to /. The alphabet changes, not the decoded data.
Padding Only one or two trailing = signs are valid. Misplaced or mismatched padding is rejected.
Data URL data:<media-type>;base64, precedes the payload. The media label describes the bytes but does not alter them.
Browser bound Text and file sources are limited to 4 MiB. Larger material must be processed elsewhere.

Privacy Notes:

The conversion runs in the current browser tab. Selected file bytes are not sent to a conversion service, but copied output and downloads contain the recovered or encoded data.

  • Treat Base64 credentials, keys, documents, and images as sensitive as their decoded originals.
  • Use file input for binary material so a text editor cannot change bytes before encoding.
  • Remove sensitive values before sharing a URL or browser state that may preserve inputs.

Worked Examples:

Recovering an unpadded token

The token dXNlcjo0Mg is Base64URL without padding. Decode it with Padding repair enabled to recover user:42. If an extra alphabetic label was copied with the token, remove that label before decoding because lenient cleanup cannot distinguish it from payload characters.

References: