Base64 Encoder Decoder
Encode UTF-8 text to standard Base64, or inspect decoded bytes as text or hex.
Enter text to encode or a standard RFC 4648 Base64 value to decode.
Output
Encoded or decoded data will appear here.
Use Encode UTF-8 or Decode Base64 to produce output.
Base64 Is a Way to Carry Bytes Through Text-Only Places
Base64 fits situations where a system needs binary data expressed with a small ASCII alphabet. Three input bytes are represented as four Base64 characters, so the encoded form is larger than the original bytes. The tradeoff is that the result travels conveniently through formats and protocols that are designed around text.
That makes Base64 common in data URLs, certificates, MIME content, API fields, small embedded assets, and serialized binary values. It does not make the underlying data secret.
Unicode Text Must Become Bytes Before It Can Become Base64
Base64 encodes bytes, not JavaScript characters. Text such as Sneha • नमस्ते • पुणे is first encoded as UTF-8 bytes and those bytes are then converted to Base64. This is why calling browser btoa() directly on arbitrary Unicode text can fail or produce the wrong mental model.
Decoding reverses the byte step. If those bytes are valid UTF-8, the UTF-8 view can display text. If they are an image fragment, compressed data, encrypted bytes, or another character encoding, the hex view is more honest than replacement characters pretending to be readable text.
Why = Appears at the End
Base64 processes input in three-byte groups and writes four encoded characters. When the final group contains only one or two bytes, padding with = completes the standard four-character output quantum. Standard RFC 4648 Base64 normally includes that padding unless the surrounding protocol explicitly says it can be omitted.
Relaxed mode is intentionally narrow: it can remove ASCII whitespace and restore missing end padding. It does not accept arbitrary junk characters or silently reinterpret another Base64 alphabet.
Base64 is not encryption
Anyone who has the encoded value can normally decode it. Do not use Base64 to protect passwords, tokens, private keys, customer data, or other secrets.
Encoded secrets are still secrets
A Base64-looking API credential or session value is not safer to paste into logs, screenshots, tickets, or public chats simply because it is unreadable at a glance.
Standard Base64 and Base64URL Are Related but Not Interchangeable
Standard Base64 uses + and /. Base64URL replaces those characters with - and _because the standard alphabet is inconvenient in URLs and filenames. Base64URL also commonly omits padding when the protocol makes the data length clear.
RFC 4648 explicitly treats Base64URL as a distinct encoding alphabet. URL-safe characters are therefore reported rather than silently converted. JWT segments, URL tokens, and other URL-safe values need Base64URL decoding rules instead of standard Base64 rules.
Canonical Form Matters When Encoded Text Is Compared or Signed
The unused pad bits at the end of an encoding should be zero. If they are not, two different Base64 strings can decode to the same bytes. Strict mode re-encodes the decoded bytes and rejects a non-canonical spelling. That distinction matters when encoded values are compared literally, cached, hashed, or used inside signed data.
RFC 4648 defines the standard alphabet, padding, treatment of non-alphabet characters, and canonical pad-bit requirement implemented by the strict decoder. Read RFC 4648
A data: URL Is More Than a Base64 Payload
A string beginning with something like data:image/png;base64, contains a media type and a data URL prefix before the actual Base64 characters. Passing the whole URL to an ordinary Base64 decoder is a format mismatch. Remove the prefix before decoding the payload, or parse the value as a data URL rather than as raw Base64.
Text Input Is Not a Substitute for Reading an Arbitrary Binary File
Encoding starts from UTF-8 text entered in the textarea. It does not read a local image, archive, PDF, executable, or other file as raw bytes. Pasting binary-looking text is still encoding the characters that were pasted, not reconstructing the original file bytes.
Large values also create several in-memory copies while converting between strings, byte arrays, Base64, and the displayed result. For very large payloads, a streaming library or command-line encoder is a better fit than a browser textarea.