Base64 Encoder and Decoder
Encode or decode Base64 text and files locally, choose standard or URL-safe output, repair missing padding, and inspect the recovered bytes.{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
{{ primaryOutput }}
| Signal | Value | Meaning | Copy |
|---|---|---|---|
| {{ row.signal }} | {{ row.value }} | {{ row.detail }} |
| Offset | Hex | Decimal | Character | Copy |
|---|---|---|---|---|
| {{ 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
| 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. |
| 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:
- RFC 4648: Base-N Encodings, RFC Editor, October 2006.
- RFC 2397: The data URL scheme, RFC Editor, August 1998.