Encode and decode text or files to/from Base64
Base64 is a binary-to-text encoding that maps arbitrary binary data into a 64-character alphabet of ASCII letters, digits, `+`and `/`plus `=` as end padding. The purpose is transport through text-only channels: email bodies (MIME was designed around this), JSON values, HTTP headers, URL parameters, and any context where raw binary would be mangled by intermediate systems expecting text. Every three input bytes (24 bits) map to four output characters (6 bits each, 24 bits total), which is why Base64 output is always a multiple of 4 characters and exactly 4/3 (about 133%) the size of the input. A 1 KB binary file becomes a 1.33 KB Base64 string; a 1 MB image becomes about 1.37 MB of Base64 text (the overhead includes padding and line breaks). The URL-safe variant (RFC 4648 §5) replaces `+` with `-` and `/` with `_` so the output can appear in URLs and filenames without escaping. This matters because `+` is interpreted as a space in application/x-www-form-urlencoded query strings and `/` breaks path parsing. JWT tokens use URL-safe Base64. The standard variant and URL-safe variant are not interchangeable: decoders need to know which they are reading or they will produce wrong output on any string containing `+``/``-`or `_`.
Initializing in your browser…
URL encode or decode text for safe use in URLs
Decode and inspect JSON Web Tokens (JWT). View header, payload, claims, expiration status, and signature without needing the secret key
Convert between Unix/Epoch timestamps and human-readable dates. Supports seconds and milliseconds with timezone information
You need to embed a small piece of text in a JSON config field that does not allow newlines or quotes, so you Base64 it.
Plain text
Hello, World!
Base64
SGVsbG8sIFdvcmxkIQ==
Base64 maps every 3 bytes of input to 4 ASCII characters from a 64-symbol alphabet, so binary or punctuation-heavy data survives transports that only tolerate plain text. The trailing `==` is padding signalling the final group was 1 byte short. It is encoding, not encryption, anyone can decode it back instantly, which the tool also does.
Base64 is a binary-to-text encoding that maps arbitrary binary data into a 64-character alphabet of ASCII letters, digits, `+`and `/`plus `=` as end padding. The purpose is transport through text-only channels: email bodies (MIME was designed around this), JSON values, HTTP headers, URL parameters, and any context where raw binary would be mangled by intermediate systems expecting text. Every three input bytes (24 bits) map to four output characters (6 bits each, 24 bits total), which is why Base64 output is always a multiple of 4 characters and exactly 4/3 (about 133%) the size of the input. A 1 KB binary file becomes a 1.33 KB Base64 string; a 1 MB image becomes about 1.37 MB of Base64 text (the overhead includes padding and line breaks). The URL-safe variant (RFC 4648 §5) replaces `+` with `-` and `/` with `_` so the output can appear in URLs and filenames without escaping. This matters because `+` is interpreted as a space in application/x-www-form-urlencoded query strings and `/` breaks path parsing. JWT tokens use URL-safe Base64. The standard variant and URL-safe variant are not interchangeable: decoders need to know which they are reading or they will produce wrong output on any string containing `+``/``-`or `_`.
Convert small images to data URIs so they load inline without extra HTTP requests.
Encode binary attachments as Base64 strings to include them in JSON request bodies.
Decode Base64 content from API responses or logs to inspect the underlying data.
Prepare files for MIME multipart messages where binary content must be text-encoded.
A common misconception is that Base64 provides any form of security. It does not. Base64 is an encoding, not encryption, anyone can decode it with no key and no computational work. The only thing Base64 gives you is safe transport through text-only channels. Putting sensitive data in Base64 and calling it "encoded for security" is a textbook security mistake and shows up repeatedly in breach postmortems. If you want to protect data in transit, use TLS; if you want to protect data at rest, use a real encryption algorithm with a proper key.
Padding rules are a frequent source of bugs. Standard Base64 pads with `=` so the output is always a multiple of 4 characters; a 1-byte input produces 4 output characters (`XX==`), a 2-byte input produces 4 (`XXX=`), a 3-byte input produces 4 (`XXXX`), and it cycles. Some variants (RFC 4648 §3.2 "unpadded") omit the padding entirely, which saves bytes but requires decoders that can handle variable-length input. This tool handles both padded and unpadded input on decode and lets you choose which to produce on encode. If you are interoperating with a specific protocol, check its spec, JWT uses unpadded URL-safe Base64, most MIME uses padded standard Base64.
The 33% size overhead makes Base64 the wrong choice in some contexts. Embedding a 5 MB image as a data URI in HTML bloats the HTML by 6.7 MB (5 MB * 1.33 + the data URI prefix), and browsers cannot cache inline data, so every page load re-downloads it. For small images (under 5-10 KB) the HTTP request overhead saved by inlining can exceed the size overhead, but for anything larger, keep the image as a separate file referenced by URL. The same tradeoff applies to sending binary data in JSON: for small payloads Base64 is convenient, but for large files a multipart/form-data upload or a separate binary endpoint is more efficient.
No. Base64 is an encoding scheme, not encryption. Anyone can reverse it without a key.
Base64 maps every 3 input bytes to 4 output characters, resulting in roughly 33% size increase.
A variant that replaces + with - and / with _ so the encoded string can safely appear in URLs without escaping.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.