Base64 Encoder & Decoder

Base64 is an encoding scheme that represents binary data using exactly 64 printable ASCII characters. The motivation is purely practical: a lot of internet protocols and file formats were designed when binary data over text channels was a problem to solve. Email's SMTP transport historically rejected anything outside printable ASCII JSON values must be valid Unicode strings URLs are restricted to a small character subset HTTP headers are line-oriented text XML attributes cannot contain raw bytes — and yet engineers constantly need to ship binary data through all of these channels. Base64 is the lingua franca that solves it. Three input bytes turn into four output characters drawn from A-Z a-z 0-9 and two extras (+/ for standard -_ for URL-safe) with padding = filling out the last group when the input length is not a multiple of three. The two big use cases are transport and embedding. Transport: email attachments (MIME) HTTP basic auth credentials S3 ETags certificate PEM blocks (BEGIN CERTIFICATE) JWT segments OAuth state OpenID Connect ID tokens. Embedding: data: URLs for inline images and fonts JSON payloads carrying file uploads environment variables for keys and secrets SQL columns storing small blobs. Whenever a system says give me a string that is safe to put in this slot but I really need to ship raw bytes Base64 is almost always the answer. The cost is a 33% size overhead which is acceptable for most non-bulk use cases — large media should never be Base64-embedded inline because the overhead becomes painful at scale.

Standard Base64 (RFC 4648 §4) uses A-Z a-z 0-9 + / and URL-safe Base64 (RFC 4648 §5) substitutes - for + and _ for /. Functionally the encoded data is identical — 64 distinct values mapped onto different glyphs. The reason both exist is the URL-and-filename problem: the standard alphabet's + and / characters are not safe in URLs query parameters filenames or filesystem paths without percent-encoding and Base64 strings that find their way into those slots routinely break in production when implementations forget to escape them. The URL-safe alphabet sidesteps the issue. When to pick which is mostly determined by what is consuming the output. JWT JWS JWE and the entire OAuth / OIDC ecosystem standardise on URL-safe Base64 with no padding. AWS S3 ETags Git object hashes when externalised MIME email attachments and most certificate PEM blocks use standard Base64. Kubernetes secrets stored in YAML use standard but cannot include = characters in some contexts and so often run unpadded. If you are wiring up a new system pick URL-safe + no-padding by default — it is the safer default and almost every modern decoder accepts unpadded input. The toolset on this page lets you flip the alphabet and padding independently and round-trips both directions.

Three classes of failure dominate Base64 bug reports. First missing padding: many decoders (notably the bare atob() in older browsers and some Python implementations) reject inputs whose length is not a multiple of four while many encoders (notably JWT libraries and some Go implementations) emit unpadded output by design. The fix is to pad before decoding by appending = characters until length % 4 === 0. Second alphabet mismatch: a standard-alphabet decoder fed a URL-safe string will silently misinterpret - and _ as illegal characters and either throw or produce garbage. The fix is to replace - with + and _ with / before decoding or use a decoder that understands both alphabets (this tool auto-detects). Third character-encoding ambiguity: Base64 encodes raw bytes not text. When the input is text the encoder must commit to a byte-level encoding first — modern code uses UTF-8 but a lot of older code emits UTF-16 Latin-1 or Windows-1252 and if you decode with the wrong assumption you get corrupted strings rather than an error. This tool always uses UTF-8 in both directions; if you are decoding output from a Java or.NET system that emitted UTF-16 the decoded bytes will look right but the text will not — recover by decoding the bytes with the correct codec on whichever side you control. For everything that does not round-trip cleanly the answer is almost always one of these three failures and the diagnostic is to look at the raw bytes rather than the decoded string.

Both use the same 64-character vocabulary structure but with different glyphs for two of them. Standard Base64 (RFC 4648 §4) uses A-Z a-z 0-9 plus + and /. URL-safe Base64 (RFC 4648 §5) replaces + with - and / with _ so the output can sit inside a URL or filename without percent-encoding. Both finish with optional = padding to round the length to a multiple of 4. Use URL-safe whenever the encoded string will end up in a query parameter JWT OAuth state Kubernetes secret name S3 object key or any other URL or filename slot — standard Base64 in those positions usually breaks because + and / require escaping.

The = character is padding. Base64 encodes 3 bytes of input as 4 characters of output so when the input's byte count is not a multiple of 3 the encoder appends one or two = characters to keep the output length a multiple of 4. Most decoders accept both padded and unpadded inputs (RFC 4648 §3.2 explicitly allows omitting padding) but some legacy implementations reject unpadded strings. JWT OAuth and JWS all use unpadded URL-safe Base64; raw S3 ETags use padded standard Base64. This generator lets you toggle padding on output and auto-restores padding on decode so you can paste either form.

No. Base64 is encoding not encryption. Anyone can decode any Base64 string with no key no secret and no setup — including this tool. The point of Base64 is to represent arbitrary binary data using a 64-character ASCII subset that survives transport over channels designed for text (email JSON URLs). It does not provide confidentiality integrity or authenticity. If you need any of those encrypt the data first (AES-GCM NaCl) and Base64-encode the ciphertext for transport.

Base64 expands binary data by roughly 4/3 — three input bytes become four output characters so a 100 KB binary becomes ~133 KB Base64. The exact growth depends on padding: with padding the output is exactly ceil(n/3) * 4 characters; without padding it is ceil(n * 4 / 3). For email attachments (MIME wraps every 76 chars with a CRLF) factor in another ~2-3% from line breaks. For inline images in HTML/CSS data: URLs expect about 33% growth before any compression — gzip and brotli will recover most of that on the wire but not in disk storage.

Yes. Click Encode file pick any file under 5 MB and the encoder runs the bytes directly without going through a text representation. For decoding paste the Base64 string and click Download to get the original binary back as a file. Everything is computed locally in your browser — file contents never leave your machine. For files larger than 5 MB encode locally with base64 < file.bin (Linux/macOS) or [Convert]::ToBase64String([IO.File]::ReadAllBytes('file.bin')) (PowerShell) — browser memory usage starts to matter beyond that size.

Yes. Base64URL is just the informal name people use for URL-safe Base64 (RFC 4648 §5). The IETF spec does not define a separate scheme; it documents Base64 with two alphabets and lets implementations pick. JWT (RFC 7519) JWS (RFC 7515) JWE (RFC 7516) and many OAuth / OIDC profiles all standardise on URL-safe + no-padding. If you are dealing with a JWT and the decoder is failing the issue is almost always missing padding — append = until the length is a multiple of 4 and try again.