Verifiable examples
The Unicode text:
Hello, world 👋is converted to UTF-8 bytes and produces this standard Base64 value:
SGVsbG8sIHdvcmxkIPCfkYs=Selecting Base64 → UTF-8 text recovers the original text exactly. The emoji uses four UTF-8 bytes, which is why passing the JavaScript string directly to a single-byte function is not reliable.
In Base64URL mode, ??? produces Pz8_. The / from standard Base64 becomes
_; clearing the padding option removes final = characters without changing
the represented bytes.
Standard Base64 and Base64URL
Base64 represents bytes with a 64-character ASCII alphabet. Every three bytes
become four six-bit values. An incomplete final group may use one or two =
padding characters.
The tool supports both RFC 4648 alphabets. Standard Base64 uses + and /;
Base64URL uses - and _ so values need fewer escapes in URLs and filenames.
The format selector is explicit because many encoded strings contain none of
those four distinguishing characters and cannot be identified safely by sight.
Before encoding, TextEncoder converts the input to UTF-8. When decoding,
TextDecoder requires the recovered bytes to form valid UTF-8 text. The tool
does not insert line breaks or normalize Unicode.
Base64 is not encryption, compression, or hashing. Anyone with the encoded value can reverse it. Use it to represent bytes as text, not to protect a password, key, or token.
Decoding rules
- The selected alphabet must match the input.
- Complete final padding,
=or==, is accepted. - Omitted padding is accepted when it can be reconstructed unambiguously.
- Spaces, tabs, and line breaks are ignored and reported.
- Existing padding must appear only at the end and complete a group of four.
- Padding bits must form a canonical representation.
- The decoded bytes must be valid UTF-8 text.
For example, SGVsbG8 is normalized internally and returns Hello. By
contrast, /w== represents a binary byte that is not valid UTF-8 on its own,
so this text-focused tool rejects it.
Unicode, files, and common failures
Two strings that look identical may contain different Unicode code points and
therefore produce different Base64 values. A composed é is not the same byte
sequence as e followed by a combining accent. Apply the normalization
required by the receiving protocol before encoding.
Images, archives, and other files are valid Base64 use cases, but their bytes
do not have to form UTF-8 text. This page deliberately handles text only. Read
Base64 text, files, and Data URLs
before removing a data: prefix or treating a binary result as text.
If an API reports incorrect padding, use the Base64 padding troubleshooting
guide. For accents, emoji, and
JavaScript btoa failures, see Base64 and UTF-8
Unicode.
Limits and privacy
Input is limited to 1,000,000 characters to protect the tab. The tool does not read files, generate Data URLs, support MIME line wrapping, or accept custom alphabets. It processes the input and output only in this page: no processing request, storage, or URL parameter contains your text.
Frequently asked questions
Should I include final padding?
Use the form required by the protocol receiving the value. The tool can emit padding or omit it, and it can decode either form when the missing characters are unambiguous. Do not remove arbitrary characters to make a value fit.
Why does the same text produce a different value elsewhere?
Check the text encoding, Unicode normalization, alphabet, and padding policy. Base64 preserves bytes, so any change before encoding changes the result.
Is entered text saved?
No. It disappears when the page is reloaded or closed and is never sent to Tools in a Tab for processing.
Technical references
The alphabets, padding rules, and test vectors are defined in RFC 4648. Text-to-byte conversion follows the WHATWG Encoding Standard.