{{ summaryTitle }}
{{ summaryLine }}
{{ badge.label }}
Choose Encode for text/file bytes or Decode for an existing Base64 string.
{{ mode === 'encode' ? 'Paste text or drop one file; bytes encode using the selected text encoding.' : 'Paste Base64 or drop a text payload; cleanup rules are in Advanced.' }}
Drop a file to encode, or a Base64 text file to decode onto the textarea.
Use UTF-8 for normal web text; Latin-1 or ASCII only for legacy byte mappings.
Choose Raw bytes preview when decoded content is binary or the text charset is unknown.
On uses - and _ instead of + and /; decoding accepts either alphabet.
{{ url_safe ? 'On' : 'Off' }}
Encode padding controls trailing = signs; decode repair adds missing = when length allows.
{{ include_padding ? 'On' : 'Off' }}
{{ fix_missing_padding ? 'On' : 'Off' }}
Accepted values: no wrap, PEM 64, MIME 76, or a custom column count of 4+.
Leave off for strict validation; turn on only for copied payloads with wrappers or separators.
{{ strip_non_b64 ? 'On' : 'Off' }}
LF is typical on Unix/web targets; CRLF fits Windows or MIME handoff.
Turn on for inline assets; MIME examples: image/png, text/plain, application/json.
{{ data_url ? 'On' : 'Off' }}

      
Field Value Copy
{{ row.label }} {{ row.value }}
# Hex Dec Char Copy
{{ b.i }} {{ b.hex }} {{ b.dec }} {{ b.ch }}
No bytes

      

      
Customize
Advanced
:

Introduction:

Many web and messaging formats still need binary data to travel through text-only channels. Base64 solves that transport problem by spelling bytes with printable characters, so an image fragment, certificate body, token, attachment part, or small inline file can sit inside text without losing the original byte values.

The tradeoff is size and readability. Base64 is usually about one-third longer than the original bytes, and the result is not meant to be read by people. It is useful because the encoded text can be copied, wrapped, embedded, or stored where raw bytes would be damaged by line endings, control characters, or character-set conversion.

Common Base64 contexts and format choices
Context Format choice that often matters
Email or PEM-style blocks Line wrapping may be expected, often at 64 or 76 characters.
URL tokens and filenames base64url avoids + and /, and padding may be omitted.
Inline browser assets A Data URL needs a media type before the encoded payload.
Copied API or log payloads Whitespace, labels, or separators can break strict decoding unless they are intentionally ignored.
Three input bytes become four six-bit lookup values and then four Base64 characters.

Two Base64 strings can represent the same bytes while looking different. One system may keep padding signs, another may strip them. A sender may use standard Base64 for a certificate and base64url for a token. A long encoded block may be folded across lines even though the decoded bytes are unchanged.

Text encoding is a separate choice from Base64. The word café has one byte sequence in UTF-8 and a different one in Latin-1, so the Base64 text changes before the Base64 rules even start. During decode, a garbled text preview may mean the bytes are binary, compressed, encrypted, or being displayed with the wrong character encoding.

Base64 does not encrypt, compress, sign, or prove trust. Anyone with the string and a decoder can recover the bytes, so encoded secrets, credentials, tokens, and private files deserve the same care as the original material.

How to Use This Tool:

Start with the direction, then match the output to the place where the encoded text will be pasted or decoded.

  1. Choose Encode for plain text or a file that needs a Base64 form. Choose Decode when the input is already Base64 and you want the recovered text or bytes.
  2. Paste text into the main field or select Browse file. For binary files, prefer file input so an editor cannot alter byte values before encoding.
  3. For text encoding, keep UTF-8 unless a legacy system specifically expects UTF-16LE, Latin-1, or ASCII. If decoded output looks wrong, switch to Raw bytes preview before treating the payload as readable text.
  4. Use URL-safe alphabet when encoding for URLs or filenames. Decode mode accepts both standard and URL-safe symbols, but the setting still helps you document the expected variant in the result fields.
  5. Open Advanced for padding, wrapping, line endings, lenient cleanup, and Data URL output. Leave Strip non-Base64 characters off unless pasted labels or separators should be discarded.
  6. Review Payload Fields for mode, byte counts, alphabet, wrapping, and padding, then use Byte Breakdown when the decoded text is not clearly human-readable.

Interpreting Results:

The primary result is copy-ready text for the current mode. In encode mode, that means Base64 text, or a complete Data URL when that option is on. In decode mode, it means decoded text or a printable byte preview, depending on the output encoding choice.

Check byte counts when comparing results. Line wrapping, Data URL prefixes, and optional padding can change the visible length while leaving the recovered bytes the same. Payload Fields is useful for confirming the variant choices; Byte Breakdown is the better check when the payload contains control bytes, non-text data, or characters that display as dots or replacement marks.

A successful decode proves only that the input can be read as Base64. It does not prove that the recovered content is safe to open, valid for a protocol, encrypted, compressed, or from a trusted sender. When decoding fails, compare strict cleanup, padding repair, and copied wrapper text before deciding that the payload itself is broken.

Technical Details:

Base64 works on octets, not on letters. A text string must first become bytes through a character encoding, while a selected file already supplies its byte stream. Once the bytes are known, Base64 reads them in 24-bit groups and writes four printable characters for each full group.

The 64-character alphabet carries six bits per output character. Standard Base64 uses letters, digits, +, and /. base64url keeps the same six-bit values but replaces the last two symbols with - and _ so the encoded text is easier to place in URLs and filenames. Padding signs are not data bytes; they mark a short final group.

Formula Core

For N input bytes, padded Base64 length L and padding count P are determined before wrapping, URL-safe symbol replacement, or a Data URL prefix is applied.

L = 4 × N 3 P = ( 3 - N mod 3 ) mod 3

Five input bytes need two Base64 groups, so padded output has eight characters. Because 5 mod 3 = 2, the final group carries one padding sign. If a format omits padding, the same bytes display as seven Base64 characters.

Transformation Core

Base64 transformation stages
Stage Example What changes
Text or file bytes Man becomes 4D 61 6E The chosen text encoding matters only for typed text; files already have bytes.
24-bit grouping 01001101 01100001 01101110 Three bytes form one group; a short final group is padded with zero bits for lookup.
Six-bit indexes 010011 010110 000101 101110 Each six-bit value selects one alphabet character.
Encoded text TWFu Wrapping, URL-safe symbols, and Data URL prefixes change presentation around the payload.
Base64 variant rules and interpretation
Variant Visible rule Interpretation
Standard alphabet Uses A-Z, a-z, 0-9, +, and /. Best when a receiving format expects conventional Base64 text.
URL-safe alphabet Replaces + with - and / with _. Useful for URL tokens and filenames; the decoded bytes are the same when the values are otherwise equal.
Padding Uses = signs only at the end. Shows whether the final group came from one or two remaining bytes.
Line wrapping Inserts line breaks at a fixed column count. Transport formatting; whitespace is normally removed before decode.
Data URL Adds data:<media-type>;base64, before the payload. Gives browser and document contexts a media type for short inline content.
Lenient cleanup Discards characters outside the Base64 alphabet after whitespace is removed. Helpful for copied wrappers, but strict mode is safer when unexpected characters may signal corruption.

Privacy Notes:

Encoding and decoding run in the browser for the built-in text and file workflow, so selected files are not uploaded to a conversion service during that workflow. The browser still handles the material you enter: copied output can go to the clipboard, opened Data URLs can be handed to a new tab, and form values may appear in the address bar for restore or sharing behavior. Avoid pasting secrets when you do not want them reflected in browser history, copied links, screenshots, or shared URLs.

  • Use file input for binary data instead of copying through a text editor.
  • Clear sensitive text from the field before sharing the page URL.
  • Treat decoded bytes, tokens, and credentials as sensitive even when they arrived as printable Base64 text.

Worked Examples:

Plain text with the standard alphabet

Encoding Man as UTF-8 produces bytes 4D 61 6E and the Base64 text TWFu. Payload Fields should show Mode as Encode, Alphabet as Standard Base64, Input bytes as 3 B, and Output bytes as 4 B.

A short token without padding

Decoding SGVsbG8 with Fix missing padding on recovers Hello. The output should report 7 input characters and 5 decoded bytes. If the same token used - or _, the decoder can still normalize those URL-safe symbols before recovering the bytes.

A pasted block with wrapper text

If decode mode reports non-Base64 characters after you paste a log line or labeled block, remove the label first when possible. Turn on Strip non-Base64 characters only when the extra characters are known wrappers or separators, then inspect Byte Breakdown to make sure the recovered hex and decimal values match the content you expected.

FAQ:

Does Base64 encrypt my data?

No. Base64 is reversible encoding. The result may look unreadable, but anyone can decode it back to bytes without a password or key.

Why did the same words produce different Base64?

Base64 starts from bytes, not from the visual words. UTF-8, UTF-16LE, Latin-1, and ASCII can turn the same visible text into different byte sequences before encoding.

Should padding signs be kept?

Keep padding for conventional Base64 unless the receiving format expects unpadded text. Some token formats omit trailing = signs because the data length is known elsewhere.

Why does decoded text look unreadable?

The recovered bytes may be binary data, compressed data, encrypted data, or text shown with the wrong output encoding. Use Raw bytes preview and Byte Breakdown before copying it as ordinary text.

Why does strict decode reject my pasted text?

Strict decode rejects characters outside the Base64 alphabet after whitespace is removed. Delete copied labels or enable Strip non-Base64 characters only when those extra characters are known wrappers.

Glossary:

Octet
An eight-bit byte, the unit Base64 encodes and decodes.
Alphabet
The 64 printable symbols used to spell six-bit values.
Padding
Trailing = markers used when the final byte group is short.
base64url
The URL and filename-safe variant that uses - and _.
Data URL
A URL form that places a media type and payload data directly inside the address string.

References: