Encoding and escaping

Base64 encoderand strict UTF-8 decoder

Convert one text value with an explicit alphabet and padding policy.

Base64 encoder

Input

Result

Conversion stays in this browser; input is not uploaded.

Encoding options

UTF-8 only. Decoding accepts complete or omitted padding and rejects nonzero pad bits. The selected alphabet is checked strictly; invalid UTF-8 bytes produce an error.

Input: 1,000,000 UTF-16 units; output: 4,000,000 units. Empty input is valid. Pasting may normalize line endings.

Enter text or load an example. Empty input converts to empty output.

Reverse uses the fresh result as input and changes direction after confirmation. It is unavailable when the result exceeds the input limit.

A Base64 encoder is useful when an API expects text represented as ASCII, but the source contains accents, Chinese or emoji. The text first becomes UTF-8 bytes; the alphabet then represents those bytes. You can encode Base64 online without changing the source character sequence.

When decoding a configuration value, a readable result alone is not enough. This workspace checks the alphabet, padding and unused bits before requiring valid UTF-8, so damaged input cannot quietly become replacement characters.

Why use this Base64 encoder?

A round trip for real Unicode text

This Base64 encoder handles supplementary characters through UTF-8, so an emoji does not fail merely because it needs more than one byte. Reverse the current result to inspect the text it represents before using it elsewhere.

An emoji passes through byte blocks and an encoded sequence, then returns as the same emoji.

Separate valid encoding from valid text

A sequence can use the correct Base64 alphabet and still contain invalid UTF-8 bytes. Decoding rejects that case instead of inserting a replacement symbol; malformed padding and noncanonical trailing bits are checked separately.

A valid sequence passes a validation gate while a damaged sequence stops at a red rejection marker.

Check the destination's conventions

01

Choose the alphabet independently

Standard uses + and /; Base64URL uses - and _. Padding is a separate encoding switch in both variants. Decoding does not guess the alphabet and accepts either exact trailing padding or none.

02

Decide when to refresh

Automatic conversion waits 350 ms after edits. Disable it to show Convert, or press Ctrl/Cmd+Enter. Changing the input, direction or options immediately disables export until the result is refreshed.

03

Inspect replacements before applying

Example, Clear and Reverse first show a preview and UTF-16 lengths. Apply confirms the replacement; Undo restores one snapshot of input, options and result. Long output is previewed up to 20,000 units, while exports remain complete.

Explicit rules for both directions

Unicode becomes bytes first

UTF-8 encoding handles accents, combining sequences and emoji without Unicode normalization. A leading U+FEFF remains part of the value; encoding adds no new BOM.

Two RFC 4648 alphabets

The Base64URL encoder changes the two punctuation symbols without bundling a padding choice. A standard decoder rejects URL-safe punctuation, and the URL-safe decoder rejects standard punctuation.

Useful error locations

Invalid alphabet characters, malformed padding and isolated surrogates report a source line and UTF-16 column. Invalid decoded UTF-8 has no invented source offset because byte decoding does not expose that location.

Whitespace is a deliberate choice

The Base64 decoder can ignore only space, tab, carriage return and line feed. Disable that option to require an uninterrupted encoded value; the result reports how many permitted whitespace units were removed.

Text boundaries and strictness

One UTF-8 value, no file import
This is text-to-Base64 conversion and its reverse. There is no file, image, URL or Data URI import, binary download, charset detection or Latin-1 mode. Remove wrappers yourself; headers and punctuation are not silently stripped.
Padding must be complete or absent
Zg== and Zg both decode to f. Zg=, an equals sign in the middle, excess equals signs and a data length of one modulo four fail. Padding options affect encoding; decoding always follows this same acceptance rule.
Canonical trailing bits
Zh== is rejected even though a permissive decoder might return f. Unused bits must be zero under this tool's strict policy; RFC 4648 permits decoders to choose this behavior rather than requiring every decoder to reject them.
Invalid bytes are not repaired
The valid Base64 sequence /w== contains an invalid UTF-8 byte and fails text decoding. Isolated UTF-16 surrogates also fail encoding. Decoded leading BOM characters are retained, including repeated BOMs; no normalization is performed.
Whitespace and line endings differ
Only SP, TAB, CR and LF in encoded input can be ignored. NBSP, form feed, vertical tab and a pasted BOM are rejected. In text encoding, spaces and line endings are content; the engine preserves CRLF, but editor pasting may normalize line endings.
Bounded input, complete output
The input limit is 1,000,000 UTF-16 units before whitespace removal; output is limited to 4,000,000 units. Oversize values fail as a whole. Empty text is valid. No MIME wrapping, per-line batches, encryption, JWT verification or draft storage is provided.

Base64 encoder questions

Does it handle accented characters and emoji?

Yes. This Base64 encoder converts Unicode text to UTF-8 bytes before encoding, so accents and supplementary emoji work. It keeps combining sequences unchanged and rejects isolated UTF-16 surrogates instead of substituting a replacement character.

What is the URL-safe variant?

Base64URL uses - and _ where standard Base64 uses + and /. Whether padding is required depends on the receiving protocol. Select both the correct alphabet and the destination’s padding convention before exporting.

Why do I get an incorrect padding error?

A partially padded value such as Zg= is rejected. Supply exact trailing padding, such as Zg==, or omit it entirely as Zg. An equals sign in the middle, excess padding and a data length of one modulo four also fail.

Can Base64 process a PDF or image?

Base64 can represent arbitrary bytes, but this page accepts only text and requires UTF-8 when decoding. It has no file or image input and does not return binary files; pasting an image’s encoded bytes may therefore produce an invalid UTF-8 error.

Is Base64 a form of encryption?

No. Anyone can decode Base64 without a secret key. Encoding does not provide confidentiality or verify that a value has not been modified; use the security mechanism required by your protocol.

Found an encoding edge case?

Return to the Base64 encoder

Use the Base64 encoder with a short sample, confirm the alphabet and padding convention, then reverse the result to check the UTF-8 text.