How to use this tool
- Enter the source in the input field.
- Choose the operation and alphabet. When encoding, select padding and one-line, 64-character or 76-character output.
- Valid input updates after a brief typing pause. You can also use the main action button. Resolve errors before copying or downloading.
- Clear input keeps the conversion settings; Undo input change restores the previous inputs after clear or reverse. Reset restores the example and default settings.
Understanding the output
Encoding first converts text to UTF-8 bytes, then represents those bytes with Base64 characters. Standard output includes padding when required. URL-safe output uses hyphens and underscores instead of plus and slash, and omits trailing padding. Decoding checks the selected alphabet before converting it to bytes. The output character total counts UTF-16 units, so an emoji may count as two or more units.
For percent-encoding a query parameter instead of Base64, use the URL Encoder and Decoder and choose component encoding.
Encoding a short greeting
Hello becomes SGVsbG8= in standard Base64 and SGVsbG8 in URL-safe output. Decoding either with the appropriate alphabet returns Hello. Encoding f in standard Base64 without padding produces Zg. Decode mode accepts it and returns f.
Encoding does not hide sensitive information
Base64 is a reversible representation, not encryption or a password-protection method. Anyone who has the encoded value can decode it. It is useful when a system expects text-safe transport of bytes, but it does not provide secrecy, integrity, or proof of who created the data.
A token containing several dot-separated pieces may use Base64url for individual segments, but decoding those segments does not verify a signature. Do not treat a readable payload as evidence that a token is trustworthy or authorized.
Know whether the underlying bytes are text
Base64 can represent any binary data, including images and compressed files. This utility is specifically for UTF-8 text. It rejects decoded byte sequences that are not valid UTF-8 instead of displaying replacement characters and pretending the content was recovered. Use a binary-aware file tool when the payload is an image, archive, or another nontext format.
Method and supported input
Valid Unicode text is converted to UTF-8 bytes before encoding. Decoding accepts the selected alphabet only, ignores formatting whitespace, and accepts omitted trailing padding. Malformed padding, invalid UTF-8 bytes, and unpaired Unicode surrogates are rejected.
Default padding retains = for standard Base64 and omits it for Base64url. Explicit padding choices override that default. Wrapping inserts LF between encoded lines; decoding ignores formatting whitespace.
- Decoded content is intended to be UTF-8 text.
Limitations
- This tool does not decode images or other binary files.
- It does not verify signatures, decrypt data, or inspect token authenticity.
- File conversion and data-URL prefixes such as data:text/plain;base64, are unsupported; paste only the encoded value. An initial Unicode byte-order-mark character is preserved when decoding text.
Common questions
Why does the URL-safe result have no equals sign?
Default padding follows the selected alphabet: URL-safe output omits padding and standard output retains it. Encoding padding lets you explicitly include or omit trailing equals signs.
Why does a valid-looking Base64 value fail to decode?
Its bytes may not be UTF-8 text, or it may use a different alphabet or malformed padding.
Which alphabet should I select for a JWT segment?
Choose URL-safe Base64 for a header or payload segment using hyphens and underscores. Paste one segment rather than the whole dot-separated token; decoding still does not verify a signature.
Sources and further reading
Reviewed on