Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 strings with URL-safe variant support.
About Base64 Encoder / Decoder
When binary data has to travel through a channel that only handles text, it needs an encoding layer first. Base64 is that layer: a binary-to-text scheme that represents arbitrary bytes using 64 printable ASCII characters, so an image, a key, or a token can pass through email, a JSON field, or a URL without being corrupted. The trade-off is size. Because every three input bytes become four characters, Base64-encoded data is about 33% larger than the original.
The encoding is defined in RFC 4648. The standard alphabet is A-Z, a-z, 0-9, and the symbols + and /, with = for padding. You see it constantly in practice: images embedded in CSS or HTML through data URIs, binary payloads carried in JSON APIs that have no binary type, keys and certificates in PEM files, and the header and payload segments of JSON Web Tokens (JWTs).
This tool encodes plain text or binary data to Base64 and decodes Base64 strings back to their original content, with a swap button to reverse the two. It supports both standard Base64 and the URL-safe base64url variant, which replaces + with - and / with _ so the result is safe in URLs and filenames. UTF-8 text is handled correctly in both directions. Everything runs in your browser, so tokens and keys you paste are never sent over the network.
How to Use the Base64 Encoder/Decoder
- Select the operation mode: choose 'Encode' to convert plain text or binary data into Base64, or 'Decode' to convert a Base64 string back to its original content.
- Paste or type your input into the text area. When encoding, enter the raw text or data you want to convert. When decoding, paste the Base64-encoded string.
- Choose the Base64 variant: select 'Standard' for the classic alphabet (A-Za-z0-9+/) or 'URL-safe' for the variant that uses - and _ instead of + and /, which is safe for use in URLs and filenames.
- The output updates as you type; there is no submit button. The result appears in the output panel on the right.
- If decoding produces garbled text, verify that the input is valid Base64. Common issues include missing padding characters (=) or stray whitespace characters that were introduced during copy-paste.
- Copy the result to your clipboard using the copy button for immediate use in your code, API request, or configuration file.
Common Use Cases
Embedding Images in HTML and CSS
Data URIs allow you to embed small images (icons, logos, simple graphics) directly into your HTML or CSS using the syntax data:image/png;base64,<encoded-data>. This eliminates an extra HTTP request for each image, which can improve page load performance for small assets. Encoding the image file to Base64 is the essential step in creating these data URIs.
Working with JSON Web Tokens (JWTs)
JWTs consist of three Base64url-encoded segments separated by dots: the header, payload, and signature. When debugging authentication issues, decoding the header and payload segments with a Base64 decoder reveals the claims, expiration time, issuer, and algorithm without needing a specialized JWT library. Understanding Base64url encoding is fundamental to working with JWTs.
Transmitting Binary Data in JSON APIs
JSON has no native binary type, so APIs that need to include binary content (such as file uploads, cryptographic hashes, or encrypted payloads) typically Base64-encode the binary data and send it as a JSON string. The receiver then decodes the string back to binary. This pattern is used by AWS APIs, Google Cloud APIs, and many other services.
Encoding Credentials for HTTP Basic Authentication
HTTP Basic Authentication requires the client to send the username and password as a Base64-encoded string in the Authorization header, formatted as 'Basic <base64(username:password)>'. While this is not encryption (Base64 is trivially reversible), it ensures the credentials can be safely transmitted in an HTTP header without special character issues.
Frequently Asked Questions
Is Base64 a form of encryption?
No. Base64 is an encoding scheme, not an encryption algorithm, and it provides no confidentiality. Anyone can decode a Base64 string trivially, without any key or secret. Its purpose is to represent binary data in an ASCII-safe format for transport through text-only channels. If you need to protect sensitive data, use actual encryption (such as AES-256-GCM) and then optionally Base64-encode the encrypted output for transport.
What is the difference between standard Base64 and Base64url?
Standard Base64 uses the characters + and / in its alphabet, and = for padding. These characters have special meaning in URLs (+ is a space, / is a path separator, = is used in query parameters). Base64url, defined in RFC 4648 Section 5, replaces + with - and / with _ to produce strings that are safe to use directly in URLs and filenames without percent-encoding. Padding with = is often omitted in Base64url since the decoder can infer the original length. JWTs and many modern web APIs use Base64url rather than standard Base64.
Why does Base64 increase the size of data by about 33%?
Base64 encodes every 3 bytes (24 bits) of input into 4 characters (each representing 6 bits). So the ratio is 4/3, which is approximately a 33.3% increase. Additionally, if the input length is not a multiple of 3, padding characters (=) are added to make the encoded output a multiple of 4 characters. This overhead is the trade-off for guaranteed ASCII safety.
Can I Base64-encode any type of file?
Yes. Base64 can encode any sequence of bytes regardless of the file type: images, PDFs, executables, compressed archives, or any other binary format. The encoding process treats the input as a raw byte stream and does not interpret the content in any way. The decoded output will be byte-for-byte identical to the original input.
Why do some Base64 strings end with = or ==?
The padding characters ensure that the encoded output length is always a multiple of 4 characters. Since Base64 processes input in 3-byte blocks, if the input has 1 remaining byte after the last full block, the output gets == padding; if 2 bytes remain, it gets = padding; if the input length is exactly divisible by 3, no padding is needed. Some implementations (especially Base64url) omit the padding entirely, since the decoder can calculate the original length from the encoded string length.
How do I know if a string is Base64-encoded?
There is no guaranteed way to detect Base64 encoding by inspection alone, since any valid ASCII string that happens to use only the Base64 alphabet would look like Base64. However, common heuristics include: the string uses only A-Za-z0-9+/= characters, its length is a multiple of 4, it ends with 0-2 padding characters, and decoding it produces coherent output. Context is usually the best indicator. If the string appears in a JWT, PEM file, or data URI, it is almost certainly Base64.