Encode text, images and files to Base64 or decode Base64 strings.
Drag & drop a file here or click to select
Base64 is an encoding scheme that converts binary data into an ASCII string. It maps every 3 bytes to 4 printable characters (A–Z, a–z, 0–9, +, /). The result is about 33% larger than the original data, but it can be safely embedded in text-based protocols like email, JSON, or HTML.
The algorithm takes the input byte stream and splits it into blocks of 3 bytes (24 bits). Each block is divided into four 6-bit groups that serve as indices into a 64-character alphabet. If the length is not divisible by 3, padding characters (=) are appended. The result is pure ASCII text.
Base64 is standardized in RFC 4648 and belongs to the binary-to-text encoding family. It exists because many protocols from the 1980s (SMTP, FTP, HTTP headers) reliably transport only 7-bit ASCII. Raw binary data such as images, compiled programs or encrypted payloads would be mangled in such channels by control bytes, line-ending conversions or charset assumptions. Base64 solves this by splitting every byte triple (24 bits) into four ASCII characters from the alphabet A-Z a-z 0-9 + / and padding the tail to a multiple of four with the = character.
Besides the standard variant, RFC 4648 also defines Base64URL, which replaces + with - and / with _ so the string fits into URLs and file names without percent-encoding. JSON Web Tokens (JWT), OAuth codes and WebPush subscriptions use exactly this variant. There is also MIME-Base64 (RFC 2045) with a hard line break every 76 characters — relevant for email attachments — plus Base32 and Base16 (Hex). Our tool implements the standard RFC 4648 variant; if you need to convert between standard and URL-safe, simply substitute those two characters.
Important: Base64 is not encryption. Anyone can reverse the string back to the original bytes with two lines of code. Use Base64 only as a transport layer, never to protect passwords, API keys or personal data. For confidential content, always put a real crypto layer such as AES-GCM, or a signed token structure such as a JWT with RS256, in front of the Base64 encoding step.
The tool runs entirely in your browser — your data never leaves your machine. Here are the five steps:
logo.png, icon.svg) into the drop zone or click it to open a file picker. Images additionally get a live preview.data: URI including MIME type, e.g. data:image/png;base64,iVBORw0KGgo....background-image:url('data:...')), JSON payloads, curl commands or documentation.These examples show typical inputs and outputs you will encounter in daily work:
Hello, World! becomes SGVsbG8sIFdvcmxkIQ== (14 bytes → 20 characters, two = as padding).admin and password secret are concatenated as admin:secret and produce the header Authorization: Basic YWRtaW46c2VjcmV0.data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=, usable directly as background-image.{"alg":"HS256","typ":"JWT"} Base64URL-encodes to eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 (no padding, -_ instead of +/).Schöne Grüße correctly encodes to U2Now7ZuZSBHcsO8w59l. The trick is to convert to bytes with TextEncoder before calling btoa() — otherwise JavaScript throws InvalidCharacterError on umlauts.Base64 is robust but has quirks. First: overhead. A 1 MB image becomes about 1.33 MB of text — bad for mobile bandwidth and cache efficiency, especially if the same asset appears on many pages. Second: UTF-8 trap. The built-in btoa() in browsers expects Latin-1, not UTF-8 — umlauts, emoji or Cyrillic throw InvalidCharacterError unless you first convert to bytes with TextEncoder. Third: URL-safe vs. standard. Pasting a standard Base64 string into a URL requires percent-encoding +, / and =, otherwise routing breaks. Fourth: whitespace and padding. Many decoders accept line breaks and missing padding, others do not — when integrating APIs verify that both sides speak the same variant (strict RFC 4648 vs. MIME). Fifth and security-critical: Base64 obscures nothing. Log files, source maps and browser DevTools render any embedded Base64 string trivially readable. Never store cleartext credentials, JWTs containing sensitive claims, or API secrets as Base64 in a file or URL. If you need reproducibly secure transport, combine Base64 with AES-GCM, HMAC or TLS.
= padding characters at the end. A 100-byte input thus becomes about 136 characters of output.= signs at the end mean?=. There are never more than two = at the end.btoa() only accepts Latin-1 (code points 0–255). A ö at code point 246 is fine, but a ß or emoji is not. Fix: first convert to UTF-8 bytes with new TextEncoder().encode(str), then Base64-encode those bytes. Our tool does this automatically.+ with -, / with _, and usually drops the = padding. That way the string fits into URLs, cookies and file names without percent-encoding. JWT, OAuth-PKCE and WebPush use Base64URL.FileReader only.