What Base64 actually is
Base64 is an encoding, not encryption or compression — it represents arbitrary binary data using only 64 printable ASCII characters (A–Z, a–z, 0–9, plus two more that vary by variant), so it can safely pass through systems that only handle plain text: email (MIME attachments), JSON/XML fields, URLs, and configuration files that would otherwise choke on raw binary bytes. It groups input into 3-byte chunks and re-encodes each as 4 output characters, which is why Base64 adds roughly 33% overhead for sufficiently large inputs, plus padding effects for short inputs (a single byte, for instance, becomes 4 characters — 300% overhead, not 33%, since padding dominates at that size). With padding, the encoded length is always a multiple of 4 (padded with = when the input isn't a multiple of 3 bytes) — but padding is optional in the URL-safe variant (see below), and this tool's own unpadded URL-safe output genuinely isn't a multiple of 4 in most cases.
Because it's reversible by design and uses no secret key, anyone can decode Base64 back to the original data — it provides no confidentiality at all. Don't use it to "hide" sensitive information; it's a transport-compatibility format, not a security control.
Standard vs. URL-safe Base64
The two variants differ in exactly two characters, plus how padding is conventionally handled. Standard Base64 (RFC 4648 §4) uses + and / as its 63rd and 64th characters, and uses = padding when required. URL-safe Base64 (RFC 4648 §5) replaces those two with - and _ — characters that don't need percent-encoding inside a URL or filename — and conventionally omits padding even when it would otherwise be required, since a trailing = would itself need escaping in a URL query string. This is the variant JSON Web Tokens (JWTs) use for their header, payload, and signature segments. The decoder here accepts both standard and URL-safe Base64 automatically; inputs containing only characters shared by both alphabets (no +, /, -, or _ at all) are inherently ambiguous between the two, since there's nothing in the string itself to tell them apart.
Common uses
Base64 shows up constantly in web development and security work: embedding small images directly in CSS or HTML as data: URIs, encoding email attachments for MIME transport, representing the header and payload of a JWT, storing binary data in JSON (which has no native binary type), and basic HTTP authentication headers (Authorization: Basic <base64>). If you're working with JWTs specifically, decoding the header and payload segments with this tool is a quick way to inspect their contents — remember the signature segment is what actually prevents tampering, not the fact that the payload is Base64-encoded rather than plaintext.
Frequently asked questions
Is Base64 the same as encryption?
No. Encryption requires a secret key and is designed to be computationally infeasible to reverse without it. Base64 requires no key at all — anyone can decode it instantly, including this page. If you need actual confidentiality, use real encryption (e.g. TLS in transit, or a proper cipher for data at rest), not Base64.
Why does my Base64 output end in one or two "=" signs?
Base64 encodes data in 3-byte groups, producing 4 output characters per group. When the input's length isn't a multiple of 3, the last group is padded with = characters to keep every encoded block the same 4-character width. The amount of padding depends on how many bytes are left over: one leftover byte produces 2 real Base64 characters plus == (8 bits split into a 6-bit first character and a 2-bit remainder padded out to 6 bits for the second — two genuine data characters, followed by two literal = characters to complete the 4-character block), and two leftover bytes produce 3 real Base64 characters plus = (16 bits split into two full 6-bit characters and a 4-bit remainder padded out to 6 bits for the third — three genuine data characters, followed by one literal =). It's a structural marker, not part of the encoded data itself, which is why URL-safe Base64 commonly omits it (a decoder can reconstruct the right amount of padding just from the string's length).
What's the difference between standard and URL-safe Base64?
Only two characters and a padding convention: standard uses + and / and uses = padding when required; URL-safe uses - and _ instead (since +, /, and = all have special meaning inside a URL and would need escaping) and conventionally skips padding even when it would otherwise be required. This decoder handles both automatically — though an input using only the characters both alphabets share is inherently ambiguous between them, since nothing in the string itself distinguishes one from the other.
I pasted Base64 and got an error about it not being valid UTF-8 text — what does that mean?
It means the Base64 itself decoded successfully into a sequence of bytes, but those bytes don't form valid UTF-8 text — you're likely looking at Base64-encoded binary data (an image, a file, encrypted data, etc.), not encoded text. This tool is built for text; decoding arbitrary binary data isn't something a text box can meaningfully display anyway.
Does this tool send my text anywhere?
No — encoding and decoding both happen entirely in your browser using the Web platform's own TextEncoder/TextDecoder and btoa()/atob(). Nothing you type or paste here is included in any network request this tool makes, and nothing is saved in browser storage. Third-party analytics tracking is also disabled on this page specifically, since it's common to paste sensitive tokens or credentials here.
Sources
Last reviewed: . Encoding/decoding follows RFC 4648 (both §4 standard and §5 URL-safe alphabets); text is handled as UTF-8 throughout.