Base64 Is an Encoding, Not Encryption
Understand the UTF-8-to-Base64 process, round trips, decoding errors, and why it provides no secrecy.
Base64 turns bytes into a limited alphabet of printable characters. That makes binary data easier to carry through systems designed for text. It does not use a secret key. Anyone who receives a Base64 string can decode it, so it should never be mistaken for a way to protect a password or confidential document.
In this guide
- See the byte conversion
- What decoding checks
- Encoding is not confidentiality
- Use a deliberate round trip
See the byte conversion
The site first converts input text to UTF-8 bytes, then encodes those bytes as Base64. “Hi” becomes “SGk=”. Decode mode reverses the process and requires the bytes to form valid UTF-8 text. The equals sign is padding associated with the Base64 representation; it is not a security marker.
A non-ASCII character generally occupies more than one UTF-8 byte, so the Base64 output can be longer than expected from the number of visible characters. To inspect those bytes directly, use Text to Hex. The two tools show the same underlying bytes in different printable forms.
InputHiOutput
SGk=
What decoding checks
Decode mode removes whitespace from the supplied Base64, decodes it, and then applies a UTF-8 decoder with fatal error handling. Malformed Base64 or bytes that are not valid UTF-8 can therefore produce an error. This tool is aimed at text, not arbitrary binary files.
If a value comes from a different character encoding, Base64 decoding alone does not identify that encoding. You need to know how the original bytes were produced. Repeatedly trying encodings until something looks readable can conceal corruption.
Encoding is not confidentiality
The Base64 alphabet and padding rules are public. Decoding requires no password or private key. Base64 can hide a string from a casual glance, but it cannot prevent someone from recovering it. Use appropriate encryption, transport security, and access controls when secrecy is required.
A Base64 string in a URL, log, or screenshot can still disclose its decoded content. Treat it with the same care as the underlying text. This site’s operation is a conversion, not a security service.
Use a deliberate round trip
Start with a short sample containing a non-ASCII character, encode it, then decode it to check the result. If the text differs, investigate encoding assumptions rather than adding more Base64 layers. RFC 4648 defines the core Base64 alphabet and representation; a system may add its own transport conventions.
Some systems use a URL-safe Base64 alphabet or omit padding. The site’s encoder uses the browser’s standard Base64 functions. If an external token fails to decode, check which variant the producing system specifies rather than changing characters by guesswork. A format mismatch is different from a wrong password because this operation has no password.
- Use Base64 for representation in text systems.
- Expect UTF-8 input and output here.
- Use encryption for secrets.
Frequently asked questions
Can anyone decode Base64?
Yes. No key is needed; the encoding is reversible by design.
Why does decoding fail for some data?
The supplied Base64 may be malformed, or its decoded bytes may not be valid UTF-8 text.
Is Base64 the same as hexadecimal?
No. Both can represent bytes as text, but they use different alphabets and output lengths.