Use our free Base64 encoder and decoder to convert text, decode JWT tokens, and parse PEM certificates. This essential tool helps developers, system administrators, and security professionals encode data for transmission, decode Base64 strings, inspect JWT authentication tokens, and extract certificate details. Includes URL-safe Base64 encoding for web applications and one-click JWT parsing to view headers, payloads, and signatures. All processing happens locally in your browser for complete privacy.
Base64 is an encoding scheme that converts binary data into ASCII text using 64 printable characters (A-Z, a-z, 0-9, +, /). This encoding allows binary data to be transmitted through systems designed for text, such as email, JSON, XML, and URLs. Base64 is not encryption or compression—it's simply a way to represent binary data in a text format that's safe for transmission across text-based protocols.
The name "Base64" refers to the 64 characters in the encoding alphabet. Every 3 bytes of binary data are converted to 4 Base64 characters, resulting in approximately 33% size increase. Despite this overhead, Base64 is essential for embedding binary data in text formats and ensuring data survives transmission through systems that might corrupt binary data.
Base64 encoding allows embedding images directly in HTML or CSS using data URIs. Instead of linking to an
external image file, the image data is encoded as Base64 and included inline. This reduces HTTP requests but
increases HTML/CSS file size. The format looks like: data:image/png;base64,iVBORw0KGgoAAAA...
SMTP email protocol was designed for text only. Email attachments use Base64 encoding to convert binary files (PDFs, images, documents) into text that can be transmitted through email servers. The MIME protocol specifies how attachments are encoded and decoded, with Base64 being the standard encoding method.
REST APIs and JSON don't natively support binary data. When transmitting files or binary content through JSON APIs, Base64 encoding converts the binary data to a string that fits in JSON format. The receiving application then decodes the Base64 string back to binary data.
HTTP Basic Authentication encodes credentials as Base64. The username and password are combined with a colon (username:password) and Base64 encoded in the Authorization header. Important: This is NOT secure encryption— Base64 is trivially decoded, so always use HTTPS with Basic Authentication to protect credentials.
Some databases and storage systems work better with text than binary. Base64 encoding allows storing binary data in text fields, though it increases storage requirements by about 33%. Modern databases often have native binary types that are more efficient.
Standard Base64 uses + and / characters, which have special meanings in URLs.
URL-safe Base64 replaces these characters with - and _, making
the encoded data safe to use in URLs without escaping. URL-safe Base64 is essential for JWT tokens, which
are often passed in URLs or headers where standard Base64 characters would cause problems.
Our tool includes a URL-safe toggle that automatically converts between standard and URL-safe Base64 formats. When encoding for use in URLs, query parameters, or JWT tokens, always enable the URL-safe option.
JWT (JSON Web Token) is a compact, URL-safe token format used for authentication and
information exchange. A JWT consists of three parts separated by dots: header.payload.signature.
Each part is Base64 encoded (URL-safe), making JWTs easy to transmit in URLs, cookies, and HTTP headers.
JWT Structure:
Our JWT decoder automatically splits the token and decodes each part, displaying the JSON contents of the header and payload. This helps developers debug authentication issues, inspect token claims, check expiration times, and verify token structure.
JWTs are encoded, not encrypted—anyone can decode and read the contents. Never store sensitive information
(passwords, secrets) in JWT payloads. The signature prevents tampering but doesn't hide the data. JWTs should
be transmitted over HTTPS and stored securely. Check the exp (expiration) claim to ensure tokens
are still valid.
PEM (Privacy Enhanced Mail) is a text format for storing certificates and keys. PEM files
contain Base64-encoded certificate data wrapped in -----BEGIN CERTIFICATE----- and
-----END CERTIFICATE----- markers. Our tool decodes PEM certificates and extracts important
information like common name (CN), issuer, expiration date, and validity period.
System administrators use PEM certificate parsing to quickly verify certificate details without opening the certificate in external tools. This is particularly useful when troubleshooting SSL/TLS issues, verifying certificate chains, checking expiration dates, or confirming that certificates match their intended domains.
Base64 encoding converts binary data to text by taking 3 bytes (24 bits) at a time and splitting them into
four 6-bit groups. Each 6-bit group maps to one of the 64 Base64 characters. If the input isn't evenly
divisible by 3, padding characters (=) are added to make the output length a multiple of 4.
For example, encoding "Hi" (2 bytes):
Hexadecimal (Base16) represents each byte as two characters (0-9, A-F), resulting in 100% size increase. Base64 is more compact, increasing size by only 33%. Hexadecimal is more human-readable for debugging binary data, while Base64 is better for transmission due to smaller size.
URL encoding (percent encoding) escapes special characters using % followed by hex digits. URL encoding is for making text URL-safe, while Base64 converts binary to text. They serve different purposes and are sometimes used together (Base64 encode binary, then URL encode the result if it contains URL-unsafe characters).
Base64 is NOT encryption—it provides no security. Anyone can decode Base64 instantly without a key. Base64 is for encoding, not securing data. If you need security, use encryption (AES, RSA) and then optionally Base64 encode the encrypted result for transmission.
Treating Base64 as encryption is a critical security mistake. Base64 encoded passwords or sensitive data in source code or configuration files are completely insecure—any attacker can decode them instantly. Never use Base64 alone for security purposes.
Forgetting URL-safe encoding causes issues when passing Base64 in URLs or HTTP headers. Standard Base64
characters + and / have special meanings in URLs and must be escaped or replaced
using URL-safe Base64.
Not handling padding correctly leads to decoding errors. Base64 padding (=) is significant and
required for proper decoding. Some systems strip padding, requiring re-adding it before decoding. The padding
ensures the output length is always a multiple of 4 characters.
Every major programming language includes Base64 encoding/decoding in its standard library. JavaScript uses
btoa() for encoding and atob() for decoding. Python has the base64
module. Java provides java.util.Base64. These built-in functions handle encoding/decoding
correctly, including padding and character set handling.
When implementing Base64 in code, always use standard library functions rather than rolling your own. The edge cases around padding, character sets, and line breaks are tricky to handle correctly. Standard libraries are well-tested and handle these issues properly.
Base64 encoding increases data size by approximately 33%, which impacts bandwidth and storage. For large files, consider whether Base64 is necessary—if the receiving system can handle binary data natively, avoid Base64 to save space. For APIs transferring large binary files, multipart form data or binary upload endpoints are more efficient than Base64-encoded JSON.
Base64 encoding/decoding is computationally inexpensive but not free. For very large files (gigabytes), the processing time becomes noticeable. Stream-based encoding/decoding handles large files more efficiently than loading entire files into memory.
No—Base64 is encoding, not encryption. Anyone can decode Base64 instantly without a key. Never use Base64 alone to protect passwords or sensitive data. Use proper encryption (bcrypt for passwords, AES for data) and transmit over HTTPS.
The equals signs (=) are padding characters ensuring the Base64 output length is a multiple of 4.
Padding is required for correct decoding. Some systems strip padding when it's unambiguous, but including it is
standard practice.
Yes—any programming language with Base64 support can decode it. JavaScript: atob(base64string).
Command line: echo "base64string" | base64 -d. Python: base64.b64decode(). This
web tool provides a convenient interface without writing code.
Base64URL (URL-safe Base64) replaces + with - and / with _
to avoid special characters in URLs. Base64URL often omits padding (=) since it can be inferred
from the string length. Use Base64URL for JWT tokens and data passed in URLs.
Some Base64 encoders insert line breaks every 64 or 76 characters for readability (RFC 2045 for MIME). These line breaks should be stripped before decoding. PEM certificates always include line breaks. Most modern systems ignore whitespace in Base64 strings during decoding.
Decoding a JWT only reads its contents—it doesn't verify the signature. To fully validate a JWT, you need the
signing secret (for HMAC) or public key (for RSA) and must verify the signature matches. Our tool decodes the
token for inspection but doesn't perform signature verification. Check the exp claim to see if
the token has expired.