Base64 turns bytes into text using a defined alphabet. It is useful for carrying binary values through text-oriented formats, but it does not encrypt them. Anyone who has the encoded value can decode it without a secret key.
Before decoding, identify whether the source uses ordinary Base64 or Base64url, whether padding is expected and whether the recovered bytes are text. A successful Base64 decode can produce a binary image, a signature or compressed data rather than a readable sentence.
Understand the six-bit groups
Base64 represents data in groups of six bits, choosing one character from an alphabet of 64. Three input bytes contain 24 bits and normally become four encoded characters. When the input ends with fewer than three bytes, padding rules or an unpadded variant describe the final group.
The Base64 text codec encodes entered text as UTF-8 before Base64 conversion. Its decode operation expects the recovered bytes to be valid UTF-8 text. That makes it a text codec rather than a general binary-file viewer.
Keep the distinction between character count and byte count. ASCII characters use one byte in UTF-8, while many other characters use several. The encoded length follows bytes, so a short visible phrase in another script can produce a longer Base64 string than its character count suggests.
Text UTF-8 bytes Base64
f 66 Zg==
fo 66 6f Zm8=
foo 66 6f 6f Zm9v
é c3 a9 w6k=The byte values in this table are hexadecimal. The examples show why one or two padding characters can appear and why non-ASCII text must pass through a defined byte encoding first.
Distinguish Base64 from Base64url
Ordinary Base64 uses plus and slash for two alphabet positions. Base64url uses hyphen and underscore instead, making the representation more convenient in URL-related contexts. Some Base64url protocols omit padding, but omission is a protocol choice rather than a universal rule for every Base64 value.
Do not mix alphabets casually or apply form parsing that turns a plus into a space. A standard Base64 value placed directly in a query can be damaged by the wrong serialisation path. Use a proper URL builder or the variant required by the protocol.
The local decoder accepts the standard Base64 alphabet, with supported whitespace and omitted-padding handling, and checks canonical trailing bits. It does not directly accept Base64url hyphens or underscores. For a known Base64url protocol, use a compatible decoder or perform the specified alphabet conversion before a standard decode. A production integration should still follow the exact format required by its protocol rather than accepting every vaguely similar string.
| Question | Why it matters | Example |
|---|---|---|
| Which alphabet? | Characters differ between variants | Plus and slash versus hyphen and underscore |
| Is padding required? | Protocols differ in accepted final form | Zg== versus an allowed unpadded Zg |
| Are line breaks permitted? | Wrapped transport formats have specific rules | MIME-style output versus compact tokens |
| What are the decoded bytes? | They may not be text | Image data, signature or UTF-8 string |
| What charset applies? | Byte-to-text conversion is separate | UTF-8 versus a legacy encoding |
Convert Unicode text through bytes
JavaScript's btoa works with a binary-string model and is not a general Unicode text encoder. Passing arbitrary Unicode text directly can fail or produce the wrong result. Encode the text to UTF-8 bytes first, then Base64-encode those bytes with an appropriate implementation.
On decode, reverse the operations: Base64 text becomes bytes, then a UTF-8 decoder produces text if the bytes are valid for that encoding. A failure at the second stage does not necessarily mean the Base64 syntax was invalid. The data may simply be binary or use another charset.
Use strict decoding when silent replacement would hide corruption. A replacement character can make an invalid byte sequence appear as readable output while losing information. For exact data interchange, report the failure and inspect the bytes instead.
Repair a Unicode round trip
Suppose a service encodes a user's name containing an accented character and a second service displays corrupted text. First compare the original UTF-8 bytes with the decoded bytes. If they match, the Base64 layer is working and the problem is likely the byte-to-text interpretation.
If the bytes differ, inspect whether the sender used a legacy encoding or a direct string-to-Base64 shortcut. Replace that path with explicit UTF-8 encoding and add a shared test vector. Test more than plain ASCII, because ASCII-only examples hide many charset mistakes.
Include a newline and an emoji in a controlled round trip. Record expected bytes and output, then verify both implementations. Do not repair the display by repeatedly encoding and decoding until it looks right; that can create a fragile dependency on the original mistake.
Keep text normalisation separate. UTF-8 encoding preserves the chosen Unicode sequence, and two equivalent-looking sequences can remain different bytes. If the application needs normalised text, define that step before encoding and apply it consistently.
Validate final groups and canonical form
Padding describes how the last encoded group relates to the original byte count. Incorrect padding, impossible lengths or invalid characters should be handled according to the protocol's rules. Do not strip arbitrary punctuation and assume the remaining text is trustworthy data.
For security-sensitive tokens, canonical representation can matter. Several textual forms accepted by a permissive decoder may describe the same bytes, while a signature or cache key operates on the original text. Decide whether verification covers encoded text or decoded bytes and keep that boundary explicit.
A decoder used for inspection can be more accommodating than a protocol parser, but it should label transformations. Accepting whitespace for convenience does not mean the production protocol permits whitespace in every field.
Decode token payloads without claiming verification
JWT compact segments commonly use Base64url. Decoding a header or payload reveals its represented data, but it does not verify the token's signature or claims. An attacker can create readable encoded JSON without possessing a trusted signing key.
Use the JWT inspector for its supported decoding and verification workflow, with an independently trusted key and expected issuer, audience and timing checks in the application. A Base64 decoder alone cannot make an authentication decision.
Do not share live tokens simply because their payload looks like ordinary text. The complete token may be a bearer credential, and the decoded claims can contain personal information. Use synthetic examples in public diagnostics.
Plan for encoding overhead
Padded Base64 length is four times the ceiling of the input byte count divided by three. For large inputs, that is roughly one third more text characters than input bytes, before surrounding JSON or transport overhead. Small inputs have proportionally larger padding overhead.
Embedding large files as Base64 in JSON can increase memory use because the application may hold the original bytes, encoded string and parsed document simultaneously. Use a file or binary transport designed for the workload when appropriate.
A data URL adds a prefix and media-type information around the encoded content. A codec expecting only Base64 may need the payload separated from that wrapper. Identify the format before pasting the entire value into a decoder.
Treat encoded secrets as secrets
Passwords, API keys and personal data remain sensitive after Base64 encoding. Logs, screenshots and support tickets can expose them just as easily once decoded. Redact based on the underlying data, not on whether the text looks human-readable.
The local codec includes converted output in its report because conversion is its purpose. Review that output before exporting or sharing. Unlike the dedicated secret generators, it cannot know whether arbitrary input represents a secret.
For repeatable testing, use published vectors and synthetic values. They provide the same encoding coverage without copying live credentials into a diagnostic workflow.
Frequently asked questions
Is Base64 a form of encryption?
No. It is a reversible representation with no secret key. Anyone can decode it. Use an appropriate encryption scheme when confidentiality is required, and keep key management separate from encoding.
Why does decoding produce unreadable output?
The recovered bytes may be binary, compressed or encoded with a different charset. Base64 syntax and text validity are separate checks. Inspect the format's documentation and use a byte-oriented tool when the data is not UTF-8 text.
Can I remove equals signs?
Only when the protocol permits an unpadded representation and the receiver handles it correctly. Some Base64url formats do; other formats expect padding. Follow the source format rather than applying one global cleanup rule.
Why did a plus sign become a space?
A form-urlencoded parser may interpret plus as space. Ordinary Base64 uses plus as an alphabet character, so the wrong transport serialisation can corrupt it. Use proper query encoding or the protocol's Base64url form.
Does decoding a JWT prove it is valid?
No. Decoding only reveals data. Signature verification, trusted key selection and claim validation are separate operations. Never grant access merely because the payload is readable JSON.
Does the codec support arbitrary binary files?
This tool's interface is designed for UTF-8 text conversion. Valid Base64 that decodes to non-text bytes may fail the text stage. Use a binary-aware workflow for images, archives or signatures that are not intended as text.
What should I test across languages?
Use empty and short inputs, all three byte-count remainders, non-ASCII text, newlines, variant alphabets and malformed input. Compare decoded bytes as well as displayed text so a charset error does not masquerade as a Base64 error.