Skip to main content
coltool
中文

Base64 Encoder and Decoder Online

Strictly encode and decode UTF-8 text with explicit Base64 or Base64URL alphabets and padding.

Input
Result
Strict mode ignores whitespace (line breaks and spaces) when decoding, but never switches variants or guesses padding. Decoding stops if the bytes are not valid UTF-8.

Strict, explicit Base64 text conversion

Process Chinese, emoji, and multilingual text as UTF-8 bytes. Choose standard Base64 or Base64URL and an explicit padded or unpadded policy; the tool never switches rules based on the input.

Which alphabet should you use?

  • Standard Base64 (+/) uses + and /. Use it for MIME email, HTTP Basic Auth, Data URLs, and APIs or configuration formats that explicitly require regular Base64.
  • Base64URL (-_) replaces + and / with - and _, avoiding escaping and special meanings in URL query strings, paths, and filenames. JWT segments normally use this alphabet.

The alphabet choice only changes the symbols used in the Base64 result. It does not change the source text encoding, which is always converted to UTF-8 bytes first.

Which padding policy should you use?

  • Pad when needed (=) retains one or two trailing = characters when the final group contains fewer than three bytes. Use it for standard Base64 interchange and systems that expect complete four-character groups. No = appears when the byte length is divisible by three.
  • Omit padding removes trailing = characters. Use it for JWTs, compact tokens, and protocols that explicitly require unpadded Base64URL.

Typical combinations are “Standard Base64 + padded” for general data interchange and “Base64URL + unpadded” for JWTs or URL tokens. Always follow the receiving protocol: Base64URL can be padded, and standard Base64 can also be explicitly unpadded.

Decoding validates the alphabet, length, padding position, and unused trailing bits. Non-canonical input and invalid UTF-8 stop without returning partial or corrupted text.

FAQ

What is the difference between Base64 and Base64URL?
Standard Base64 uses + and /, while Base64URL uses - and _ for URLs and JWTs. The tool does not auto-detect; choose the intended variant explicitly.
Why is there no = at the end of the encoded result?
= is padding, not a required suffix. No padding is needed when the UTF-8 byte length is divisible by 3; one remaining byte produces == and two remaining bytes produce =.
Is whitespace ignored automatically?
When decoding, yes. Formats like MIME and PEM wrap Base64 across lines, so all whitespace is stripped before decoding. Any other disallowed character still raises an error rather than being silently fixed.
Why can some Base64 not be displayed as text?
Base64 can carry arbitrary binary bytes. This version decodes UTF-8 text only and reports non-UTF-8 bytes instead of producing replacement characters.
Is the content uploaded?
No. UTF-8 conversion and Base64 processing run entirely in your browser.