Base64 Encoder/Decoder

Convert any text to Base64 encoding instantly. Our encoder handles UTF-8 characters, JSON strings, HTML, and any text input.

Copy the Base64 output for use in:

• APIs
• data URIs
• email encoding
• configuration files

Decode any Base64 string back to readable text. Paste Base64-encoded content and see the original text instantly.

Handles:

• standard Base64
• URL-safe Base64
• Base64 with or without padding characters

Base64 encoding works by converting binary data into a set of 64 printable ASCII characters, as defined in RFC 4648 from the IETF.

The algorithm takes the input bytes and regroups them from 8-bit bytes into 6-bit chunks, since 2 to the power of 6 equals exactly 64 possible values. Each 6-bit group maps to one character in the alphabet A-Z, a-z, 0-9, plus, and slash.

Because every 3 input bytes (24 bits) become 4 output characters, the encoded text is roughly 33 percent larger than the original. When the input length is not a multiple of 3, one or two equals signs are appended as padding, per the RFC 4648 specification.

Base64 is encoding, not encryption, and it provides zero security or confidentiality. Anyone can decode a Base64 string instantly because no secret key is involved, and the reversible mapping is publicly documented in RFC 4648.

OWASP explicitly warns that Base64 is not a substitute for cryptography and should never be used to protect passwords, tokens, or personal data. Its only purpose is safe transport of binary data through text-only channels such as email, URLs, and JSON.

For genuine confidentiality, use standardized encryption like AES-256 as recommended by NIST, and for integrity use hashing such as SHA-256. Treat any Base64 string in your logs as fully readable plaintext.

URL-safe Base64 is a variant defined in Section 5 of RFC 4648 that replaces the plus character with a hyphen and the slash character with an underscore.

This substitution matters because plus and slash have reserved meanings in URLs and file paths, where they can be misinterpreted or require percent-encoding. The URL-safe alphabet lets encoded values travel inside query strings, path segments, and filenames without corruption.

Padding equals signs are often omitted in this context, since a decoder can infer the original length. JSON Web Tokens, described in RFC 7519, rely on this base64url encoding for their header and payload segments, which is why JWT strings never contain plus or slash characters.

Base64 increases data size by about 33 percent because it represents every 3 bytes of input using 4 output characters.

Three bytes contain 24 bits, and Base64 splits those 24 bits into four 6-bit groups, so the 4-to-3 character ratio adds one-third to the length, as specified in RFC 4648. Padding adds up to two more characters on the final block.

This overhead is the deliberate tradeoff for ASCII compatibility: binary data that would break email or JSON becomes fully text-safe. According to MDN Web Docs, this is why embedding images as Base64 data URIs makes HTML and CSS files noticeably larger than linking the original binary file directly.

To encode a file or image to Base64, the raw bytes are read and passed through the standard RFC 4648 algorithm, producing a text string you can embed directly in code.

A common use is the data URI scheme documented by MDN Web Docs, where an image becomes a self-contained src value such as data:image/png;base64 followed by the encoded bytes. This eliminates a separate HTTP request, which can speed up loading of tiny icons.

However, because Base64 adds 33 percent size and cannot be cached separately, it is best reserved for very small assets. Larger images, fonts, and PDFs are usually served as regular binary files rather than inlined Base64.

Base64 handles Unicode by first converting text into UTF-8 bytes, then encoding those bytes with the standard Base64 alphabet. Base64 itself only operates on raw bytes, so the character encoding step happens before encoding and after decoding.

UTF-8, defined in RFC 3629 and maintained alongside the Unicode Standard from the Unicode Consortium, represents emojis, CJK ideographs, and accented letters as multi-byte sequences that Base64 then preserves exactly. This two-step process is why our tool correctly round-trips characters like the euro sign or an emoji.

In JavaScript, MDN Web Docs notes that the legacy btoa function only accepts Latin-1, so modern code encodes to UTF-8 bytes with TextEncoder before calling btoa.

Base64 is used wherever binary data must travel through systems that only handle text.

• Email attachments are Base64-encoded under the MIME standard defined in RFC 2045, which is how images and documents survive plain-text mail transport.
• Web pages embed small images and fonts as Base64 data URIs, as documented by MDN Web Docs.
• JSON Web Tokens per RFC 7519 encode their claims as base64url strings, and HTTP Basic Authentication, described in RFC 7617, Base64-encodes the username and colon password pair.
• Base64 also appears in API payloads, TLS certificates in PEM format, and configuration files.

In every case, the goal is safe, lossless transport rather than compression or security.

The most common Base64 mistake is treating it as a security measure, when RFC 4648 defines a fully reversible, unkeyed transformation that anyone can decode.

• Another frequent error is mixing standard and URL-safe alphabets, causing decode failures when plus or slash characters are swapped with hyphen and underscore.
• Missing or incorrect equals-sign padding also breaks strict decoders, though many, including MDN Web Docs implementations, tolerate absent padding.
• Developers often forget the UTF-8 step and get garbled text for non-ASCII input.
• Finally, encoding already-Base64 data by accident doubles the overhead.

Verifying the exact variant, padding rules, and character set against the RFC 4648 specification prevents nearly all of these decoding failures.

Base64, Base32, and hexadecimal are all binary-to-text encodings defined together in RFC 4648, but they trade density for readability differently.

• Hexadecimal uses 16 characters and doubles the data size, making it the most human-readable and common in hashes and color codes.
• Base32 uses 32 case-insensitive characters, grows data by about 60 percent, and avoids ambiguous symbols, which suits case-insensitive systems and TOTP secrets.
• Base64 is the most compact of the three at roughly 33 percent overhead, using 64 characters.

Choose hexadecimal for debugging and short identifiers, Base32 when case sensitivity is a problem, and Base64 when compactness matters most, as the IETF guidance in RFC 4648 makes clear.