Encode or decode Base64 strings instantly. All processing happens in your browser.
Encode binary data (images, files) to text for transmission or storage.
Encode special characters in URLs and filenames safely.
Encode credentials or data payloads for APIs and web services.
Basic encoding for sensitive text without full encryption.
Base64 is a binary-to-text encoding scheme that converts arbitrary binary data into a string of 64 printable ASCII characters. The name comes from the character set: uppercase A-Z (26), lowercase a-z (26), digits 0-9 (10), and the symbols + and / — totaling 64 characters, or exactly 2^6, which means each character encodes exactly 6 bits of information. The purpose of Base64 is to represent data that is fundamentally binary — an image file, a cryptographic key, a compressed payload — in a form that can traverse text-only systems like email protocols, JSON payloads, and URL parameters without corruption.
Base64 processes input in chunks of 3 bytes (24 bits) and outputs 4 characters (4 x 6 bits = 24 bits). Here is how the word "Man" becomes "TWFu":
If the input is not a multiple of 3 bytes, padding is applied. A single remaining byte (8 bits) produces two 6-bit groups with four bits of zero-padding, yielding 2 output characters plus ==. Two remaining bytes produce 3 output characters plus =. The padding character signals to the decoder how many bytes the original data contained. This is why Base64 output is always a multiple of 4 characters long.
The original and most important use case. SMTP — the email transmission protocol — was designed for 7-bit ASCII text in the 1980s and cannot transmit arbitrary binary data. MIME (Multipurpose Internet Mail Extensions) solved this by encoding binary attachments as Base64 within the email body. Every PDF, image, or document you send via email is Base64-encoded in transit. The format header Content-Transfer-Encoding: base64 signals this to the receiving client.
A data URI embeds a file directly into a URL using the format data:[mediatype];base64,[data]. For example: <img src="data:image/png;base64,iVBORw...">. This eliminates a separate HTTP request for the file, reducing page load time for small assets like icons and logos. The tradeoff: Base64 expands the data by ~33%, so for large images, a separate file request with caching is more efficient than an inline data URI.
REST and GraphQL APIs send data as JSON, which is a text format that cannot natively contain raw binary bytes. When an API endpoint needs to return binary data — a generated PDF, a thumbnail image, a digital signature — it Base64-encodes it and embeds it as a string field inside the JSON response. The client then decodes it back to binary. This pattern appears in the Stripe API (invoice PDFs), AWS Lambda responses, and Google Cloud Vision API image annotations.
The Authorization: Basic header carries credentials as Base64(username:password). This is not encryption — the credentials are trivially decoded by anyone intercepting the request — which is why Basic Auth must always be combined with HTTPS. The encoding simply ensures that non-ASCII characters in usernames or passwords do not break the header parsing.
This is the single most important distinction to understand. Encoding transformations are reversible without any secret. They are designed for compatibility, not confidentiality. Given any Base64 string, anyone with a decoder (like this tool) can recover the original data in microseconds. There is no key, no password, no protection.
Encoding: transforms data format for transport. Reversible by anyone. No secret required. Examples: Base64, URL encoding, hex encoding.
Encryption: transforms data for confidentiality. Reversible only with a secret key. Examples: AES-256, ChaCha20, RSA.
Hashing: one-way transformation. Not reversible at all. Used for verification, not protection. Examples: SHA-256, bcrypt, Argon2.
Mistaking encoding for encryption is a common and dangerous misclassification. Storing a password as Base64 (unchanged and easily decoded) is functionally identical to storing it in plaintext. A Base64-encoded API token is no more secure than the raw token. Never use Base64 for security purposes.
Base64 encoding always increases data size. Since 3 input bytes (24 bits) produce 4 output characters (each representing 6 bits, stored as an 8-bit ASCII byte), the expansion ratio is 4/3 = approximately 33.3% larger than the original binary data. A 300 KB image becomes roughly 400 KB when Base64-encoded. This is the primary drawback of Base64 for large payloads: you pay a third more bandwidth and storage for text-safe transport. For small values — a 128-byte API key, a 1 KB thumbnail — the overhead is negligible. For large files, consider transmitting or storing the binary directly and encoding only when the text constraint is unavoidable.
The standard Base64 alphabet uses + and / as its last two characters. These are problematic in URLs and filenames: + is interpreted as a space in URL query strings, and / collides with path separators. URL-safe Base64 (also called base64url in RFC 4648) replaces + with - and / with _, and often omits the trailing = padding. This variant is used in JSON Web Tokens (JWTs), OAuth 2.0 state parameters, and any scenario where Base64 data appears in a URL. If you are encoding data for a query parameter, use the URL-safe variant to avoid accidental corruption.
This encoder uses the browser's built-in btoa() and atob() functions for standard Base64 operations. Unicode support is handled by first passing the input through encodeURIComponent() to convert multi-byte characters into a byte-safe ASCII representation before encoding. All processing runs locally in your browser — your input text is never sent to any server, stored, or logged. This matters because encoding and decoding operations are often performed on data that is already sensitive or private.