Base64 Encoder and Decoder

Base64 encoding converts binary data and text into an ASCII string format designed for reliable transmission across web APIs, email protocols, and data URLs. This free online Base64 encoder and decoder runs entirely in your browser with full UTF-8 emoji and international character support, RFC 4648 URL-safe mode, PEM/MIME line wrapping, and real-time payload size analytics. No data is ever transmitted or stored on an external server.

Free developer utility · runs client-side

Base64 Encoder & Decoder

Encode plain text and UTF-8 strings into Base64 or decode Base64 payloads back to text with real-time validation, URL-safe support, and size metrics.

  • UTF-8 & Emoji Safe
  • Standard & URL-Safe (RFC 4648)
  • PEM & MIME Line Wrapping
  • Real-Time Size Ratios
  • 100% Client-Side Privacy

Input & conversion settings

Input is processed instantly as UTF-8 bytes. Zero server round-trips.

Characters: 0 Lines: 0 UTF-8 Bytes: 0

Validation & payload metrics

Enter or paste text above to inspect conversion metrics, integrity scores, and size ratios.

Conversion output

Output Characters: 0 Lines: 0

Bitstream inspection & diagnostics

First 3-byte chunk mapping: 24 input bits grouped into four 6-bit Base64 indices

Enter text or Base64 above to inspect 8-bit to 6-bit binary transformations.

Diagnostic notes

  • Info Enter plain text or Base64 data to begin processing.

What is Base64 encoding and how does it work?

Base64 is a binary-to-text encoding scheme that translates raw binary octets (bytes) into a restricted set of 64 printable ASCII characters. Designed during the early evolution of computer networking, Base64 solves a fundamental problem: many legacy communication channels—such as email protocols (SMTP), HTTP headers, and URL query strings—were designed exclusively for 7-bit ASCII text. When binary data containing arbitrary bytes (values between 0 and 255) passes through these channels, control characters (such as null bytes, carriage returns, or end-of-file markers) can be mangled, truncated, or misinterpreted by intermediate gateways and proxies.

By representing arbitrary data using only 64 characters that are guaranteed to pass cleanly through any ASCII-compliant router, server, or parser, Base64 ensures complete data integrity during transit. The 64-character alphabet specified in RFC 4648 consists of:

  • 26 uppercase letters: A through Z (representing binary index values 0 to 25)
  • 26 lowercase letters: a through z (representing binary index values 26 to 51)
  • 10 numerical digits: 0 through 9 (representing binary index values 52 to 61)
  • 2 special symbols: + (plus, index 62) and / (forward slash, index 63)

In addition to the 64 alphabet symbols, the equals sign (=) is reserved as a padding character to indicate that the original binary input did not align evenly onto a three-byte boundary.

The mathematics of 6-bit grouping and payload expansion

To understand why Base64 expands payload size by exactly 33.33%, consider the mathematical relationship between bits and characters. Standard computers store data in 8-bit bytes (octets), yielding \(2^8 = 256\) possible values per byte. In contrast, Base64 uses a radix-64 number system, where each character represents \(2^6 = 64\) possible values (6 bits).

The smallest common multiple between 8-bit input bytes and 6-bit Base64 units is 24 bits. Therefore, the encoding algorithm processes binary data in discrete 24-bit blocks:

  1. The algorithm takes three consecutive 8-bit input bytes: \(3 \times 8 = 24\text{ bits}\).
  2. These 24 contiguous bits are sliced into four 6-bit integers: \(24 \div 6 = 4\text{ groups}\).
  3. Each 6-bit integer (ranging from 0 to 63) is looked up in the Base64 alphabet table to produce one ASCII character.

Because every 3 input bytes become 4 output characters, the output size is strictly calculated as:

$$\text{Base64 Length} = \left\lceil \frac{N}{3} \right\rceil \times 4$$

where \(N\) represents the raw input byte count. The data expansion ratio is \(\frac{4}{3} = 1.3333...\), meaning Base64 encoding adds approximately 33.33% overhead to the original payload footprint (excluding any additional newline characters introduced by line wrapping).

How Base64 padding works

Real-world data streams rarely arrive with an exact multiple of 3 bytes. When the total byte count is not divisible by 3, the final 24-bit block is incomplete. The RFC 4648 standard specifies explicit padding rules to ensure that decoders can reconstruct the exact original byte stream without guessing:

Remaining Input Bytes Total Bits Available 6-Bit Chunks Generated Padding Required Final Block Output
3 bytes (remainder 0) 24 bits 4 full chunks 0 padding characters XXXX
2 bytes (remainder 2) 16 bits + 2 zero bits = 18 bits 3 chunks 1 padding character (=) XXX=
1 byte (remainder 1) 8 bits + 4 zero bits = 12 bits 2 chunks 2 padding characters (==) XX==

Notice that a Base64 string can never legitimately have 3 padding characters (===), nor can a decoded block end with a single standalone character, because 1 Base64 character contains only 6 bits, which is insufficient to form even a single 8-bit byte.

Standard Base64 vs. URL-Safe Base64 (RFC 4648)

While standard Base64 works seamlessly inside email bodies and generic binary wrappers, it introduces severe parsing bugs when embedded in web applications, REST API parameters, or file paths. Standard Base64 relies on the plus sign (+) and forward slash (/), both of which possess reserved syntactic meanings in URLs:

  • In URL query parameters, + is interpreted by web application servers as an encoded space character (%20). If a standard Base64 string containing + is submitted in a GET query, the receiving server converts the plus into a space, permanently corrupting the decoded binary stream.
  • In URI paths and file systems, / denotes folder directory delimiters, causing routers and reverse proxies to misroute requests or trigger 404 Not Found errors.
  • The padding character = is reserved in URL query strings as the key-value separator, requiring percent-encoding to %3D to prevent query string truncation.

To eliminate these issues, RFC 4648 §5 established the URL and Filename Safe Alphabet (often abbreviated as Base64URL). Base64URL replaces index 62 (+) with a hyphen (-) and index 63 (/) with an underscore (_). Furthermore, modern web specifications—most notably JSON Web Tokens (JWT, RFC 7515)—explicitly mandate stripping all trailing = padding characters to ensure tokens remain compact and URL-clean.

Specification Index 62 Index 63 Padding (=) Primary Use Cases
RFC 4648 §4 (Standard) + / Required (=, ==) HTTP Basic Auth, XML, Data URLs, Cryptography
RFC 4648 §5 (URL-Safe) - _ Optional / Omitted JWTs (RFC 7515), OAuth2 tokens, URL parameters
RFC 2045 (MIME) + / Required (=) Email attachments, max 76 chars per line
RFC 7468 (PEM) + / Required (=) TLS certificates, RSA keys, 64 chars per line

Handling UTF-8, emojis, and multi-byte character encoding

A frequent trap in JavaScript development occurs when developers attempt to encode non-English text using the browser's native window.btoa() and window.atob() functions. The native btoa() function expects a "binary string" where every single character's code point occupies no more than 8 bits (values between 0x00 and 0xFF).

When a string contains characters beyond the Latin-1 range—such as accented letters (é, ü), non-Latin alphabets (Arabic, Cyrillic, Greek, Hebrew), East Asian ideographs (Chinese, Japanese, Korean), or emojis (🚀, 💡)—their Unicode code points exceed 255. Passing these characters directly to btoa() throws an unhandled InvalidCharacterError: 'btoa' failed: The string to be encoded contains characters outside of the Latin1 range.

Similarly, using atob() directly on multi-byte UTF-8 data produces "mojibake"—scrambled characters where two or three separate bytes of a single UTF-8 code point are interpreted as independent Latin-1 glyphs (for example, displaying é instead of é).

This tool overcomes native browser limitations by integrating the modern TextEncoder and TextDecoder web APIs:

  1. When encoding, the input string is converted into a UTF-8 Uint8Array byte sequence using new TextEncoder().encode(str). Each Unicode character is transformed into its exact 1-, 2-, 3-, or 4-byte UTF-8 representation.
  2. These raw bytes are converted into a binary character stream in memory-safe chunks, preventing stack overflow errors on long payloads, and encoded via Base64.
  3. When decoding, the Base64 string is converted back into raw bytes and decoded using new TextDecoder('utf-8', { fatal: true }). If the payload contains valid UTF-8 text, the exact characters and emojis are restored losslessly. If the payload contains arbitrary binary data (such as an encrypted ciphertext or compiled executable buffer), the tool reports the binary structure cleanly rather than crashing.

Common developer use cases for Base64

Base64 encoding is an indispensable utility across modern software engineering, API integrations, and web optimization:

  • HTTP Basic Authentication: When connecting to REST APIs or microservices using Basic Auth, client applications transmit credentials in the Authorization request header. The username and password are joined with a colon (username:password) and Base64-encoded: Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=.
  • Data URLs and Asset Inlining: Web performance engineers embed small SVG icons, 1x1 tracking pixels, and custom web fonts directly into CSS and HTML files using the Data URL scheme (data:image/svg+xml;base64,...). This eliminates additional HTTP round-trips for micro-assets.
  • Webhook Payload Verification: Enterprise webhook providers (such as Stripe, GitHub, and Shopify) often transmit binary HMAC-SHA256 signature hashes in Base64 format within webhook headers, allowing recipient applications to verify authenticity before processing event data. Pair this with our Webhook Payload Builder to test mock API events.
  • Email Attachments (MIME): Standard email protocols are inherently text-based. When you attach a PDF, image, or spreadsheet to an email, the email client encodes the binary attachment into MIME Base64 chunks formatted to 76 characters per line (RFC 2045).
  • SSL/TLS Certificates and Private Keys: Digital identity certificates (X.509) and cryptographic keys are distributed in Privacy-Enhanced Mail (PEM) containers. The binary ASN.1 DER certificate is Base64-encoded, wrapped at 64 characters per line, and bounded between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers (RFC 7468).

Security considerations: Encoding is not encryption

One of the most persistent security vulnerabilities in web architecture is confusing encoding with encryption:

  • Encoding (Base64): A publicly known, deterministic mathematical algorithm designed for data transport. Base64 requires no cryptographic key, password, or secret. Anyone who intercepts a Base64 string can decode it back to plaintext in a fraction of a millisecond. Base64 provides zero confidentiality.
  • Encryption (AES-256, RSA): A cryptographic process that transforms plaintext into ciphertext using a secret key. Without the corresponding decryption key, the ciphertext cannot be reversed by an unauthorized party.
  • Hashing (SHA-256, bcrypt): A one-way cryptographic function designed to verify integrity or store credentials safely. Hashes cannot be reversed.

Never store unencrypted passwords, API tokens, session secrets, or personally identifiable information (PII) in Base64 format in local storage, cookies, or public repositories. If sensitive credentials must be transmitted across an API, encrypt the payload first using a modern cipher (such as AES-GCM) before encoding the resulting binary ciphertext into Base64 for transport.

Frequently Asked Questions (FAQ)

Why does Base64 make my data 33% larger?

Computers typically store information in 8-bit bytes. Because Base64 uses only 64 characters, each character can carry only 6 bits of information (\(2^6 = 64\)). Slicing 8-bit bytes into 6-bit chunks means that 3 original bytes (24 bits) require 4 Base64 characters (24 bits) to represent. This 4-to-3 ratio results in a 33.33% increase in data size. If line wrapping is added (such as PEM 64-character or MIME 76-character formatting), newline characters slightly increase this overhead further.

Can any binary file be converted into a Base64 string?

Yes. Any digital file—whether an image (PNG, JPEG), audio clip (MP3), video (MP4), compiled executable, or PDF document—is fundamentally a sequence of bytes. Any byte sequence can be encoded into Base64 and subsequently decoded back into the identical binary file without loss of information. However, because of the 33% size expansion, Base64 is generally reserved for small assets, headers, and tokens rather than large media streaming.

What causes an "InvalidCharacterError" when using JavaScript's window.btoa()?

The native browser window.btoa() function was developed in the early days of JavaScript and only supports Latin-1 characters (code points 0 to 255). Any character outside this range—including emojis, Chinese, Japanese, Korean, Arabic, Cyrillic, or mathematical symbols—causes btoa() to throw an InvalidCharacterError. This tool prevents this error by pre-converting text into standard UTF-8 byte arrays using the modern TextEncoder API before encoding.

How does Base64 differ from URL encoding (percent-encoding)?

URL encoding (percent-encoding) replaces specific non-ASCII and reserved characters with a percent sign followed by two hexadecimal digits (such as %20 for a space or %2F for a slash), leaving standard alphanumeric characters untouched. In contrast, Base64 completely transforms the entire payload into a continuous stream of 6-bit radix-64 characters. While URL encoding is suited for individual query parameter values, Base64 is designed for packing complete binary data structures, cryptographic tokens, and complex payloads.

Is padding always required at the end of a Base64 string?

Under strict RFC 4648 §4 standard encoding, padding with equals signs (=) is mandatory so that the total string length is an exact multiple of 4. However, under RFC 4648 §5 (URL-safe Base64) and specifications like JSON Web Tokens (JWT), padding is deliberately omitted because equals signs interfere with URL parsing and require percent-encoding. A robust decoder can deduce the missing bits without explicit padding by evaluating the string length modulo 4.

Does this online Base64 tool log or transmit my input data?

No. This tool runs 100% client-side inside your web browser using vanilla JavaScript and local browser APIs (TextEncoder, TextDecoder, and btoa). No data, text, JSON, or tokens are ever sent across the network, logged on a server, or saved to browser cookies or local storage. You can verify this by disconnecting your internet connection or inspecting the network activity in your browser's Developer Tools while using the tool.

Explore related developer and automation tools

Accelerate your technical workflows and data pipelines with our suite of free browser utilities: