Base64 dekodieren
Base64 Decode & Encode converts text and binary data between raw bytes and the RFC 4648 Base64 and base64url alphabets, handles line-wrapped MIME input, and automatically detects JSON Web Tokens to show their header and claims. Everything runs locally; tokens are decoded, never transmitted.
Die Oberfläche dieses Tools ist auf Englisch.
(empty result)
Die folgende Anleitung ist nur auf Englisch verfügbar.
How does Base64 encoding work?
Base64 is one of the foundational encoding algorithms of computer networking and modern web systems, specified formally in RFC 4648 (and historically in RFC 1421 and RFC 2045). Its primary purpose is not encryption or obfuscation, but rather safe binary-to-text serialization. Many legacy protocols—notably early SMTP email systems, HTTP header parsers, and XML document schemas—were originally engineered to transmit 7-bit ASCII characters reliably. When raw 8-bit binary payloads such as JPEG images, compiled WebAssembly modules, cryptographic keys, or encrypted blocks are transmitted across arbitrary gateways, unprintable control characters (such as NULL bytes, CR, LF, or byte sequences with the high bit set) can be misinterpreted or stripped by intermediate proxies. Base64 resolves this vulnerability by projecting any sequence of arbitrary 8-bit bytes into a universally recognized 64-character subset of ASCII printable characters.
The 24-Bit to 32-Bit Transformation Pipeline
The underlying arithmetic of Base64 is remarkably elegant and mathematically deterministic. The encoder processes the input byte stream in sequential blocks of 3 bytes (24 bits). Because each standard Base64 character represents 6 bits of information (2⁶ = 64), each 24-bit block is cleanly partitioned into exactly four 6-bit indices. Each index (a number ranging from 0 to 63) corresponds to an entry in the standard Base64 lookup table:
- Indices 0 through 25 represent uppercase letters
AthroughZ - Indices 26 through 51 represent lowercase letters
athroughz - Indices 52 through 61 represent numerals
0through9 - Index 62 represents the plus symbol
+ - Index 63 represents the forward slash
/
Because 3 input bytes (24 bits) produce 4 output characters (32 bits), Base64 encoding inherently introduces a constant 33.33% payload expansion ratio (4/3). When combined with potential line wrapping or URL escaping, the resulting footprint is always roughly one-third larger than the source binary data. For small tokens, cryptographic signatures, or inline images, this overhead is negligible compared to the interoperability guarantees it provides.
Padding Rules and Tail-End Byte Alignment
Because real-world payloads rarely have byte lengths that are exact multiples of 3, the Base64 specification specifies rigorous padding semantics using the equals sign (=):
- Remainder of 1 Byte (8 bits): When an input stream terminates with a single unpaired byte, those 8 bits are padded on the right with four zero bits to create a 12-bit sequence. This yields two 6-bit Base64 characters. To preserve the mandatory 4-character block boundary, two padding characters (
==) are appended at the end. - Remainder of 2 Bytes (16 bits): When an input stream terminates with two unpaired bytes, those 16 bits are padded with two zero bits to create an 18-bit sequence. This yields three 6-bit Base64 characters. A single padding character (
=) is appended to complete the 4-character block.
Standard Base64 vs. URL-Safe Base64 (base64url)
Standard RFC 4648 Base64 relies on + and / for indices 62 and 63. However, within URI path segments, query strings, and form-urlencoded POST requests, both of these characters possess reserved syntactical meanings. In URIs, + represents an encoded whitespace character, while / denotes structural directory hierarchy. If standard Base64 strings are placed directly in URLs without percent-encoding (e.g. %2Band %2F), backend web servers frequently corrupt the payload before decoding.
To eliminate this hazard, RFC 4648 Section 5 standardized the URL-Safe Alphabet (often abbreviated as base64url). In this variant, + is replaced with -(hyphen) and / is replaced with _ (underscore). Trailing equals-sign padding is dropped too, because the length of the string modulo 4 provides sufficient mathematical information to reconstruct missing bits upon decoding. Modern web standards—most prominently JSON Web Tokens (RFC 7519), WebAuthn credentials, and OAuth 2.0 PKCE code verifiers—mandate the base64url specification exclusively.
Anatomy of JSON Web Tokens (JWT)
A JSON Web Token (RFC 7519) is a compact, URL-safe means of representing signed claims between two parties. Every JWT is structured into three distinct base64url segments separated by ASCII periods:
1. Header (base64url): Declares algorithm and token type (e.g. {"alg": "HS256", "typ": "JWT"})
2. Payload (base64url): Contains identity claims, issuer (iss), subject (sub), and expiration timestamp (exp)
3. Signature: Cryptographic hash or signature verifying that the header and payload have not been tampered with
The ToolsByUs Base64 tool automatically evaluates the token geometry of any pasted string. When three period-delimited segments with valid JSON structures are encountered, it immediately renders an inspection interface detailing human-readable dates and claim breakdowns without sending secret JWTs over any network.
Which keyboard shortcuts does the Base64 decoder support?
What is inside the first segment of a JWT?
A JSON Web Token's header is ordinary Base64url. Decoding it needs no key and proves nothing about the token — it only says which algorithm the issuer claims to have used.
Base64url
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Decoded text
{"alg":"HS256","typ":"JWT"}Base64 is an encoding, not encryption: anyone holding the string can read this. Never put a secret in a token segment and assume the encoding hides it.
Frequently asked questions
How does Base64 encoding represent binary data as ASCII text?
Base64 operates on 24-bit chunks of binary data, which corresponds to 3 standard 8-bit bytes. These 24 bits are partitioned into four 6-bit groups (since 2^6 = 64). Each 6-bit integer (ranging from 0 to 63) maps directly to a predefined index table consisting of uppercase A-Z (0-25), lowercase a-z (26-51), digits 0-9 (52-61), plus '+' (62), and '/' (63). If the input byte length is not divisible by 3, the final block is padded with zero bits, and '=' padding characters are appended to satisfy the 4-character alignment constraint.
What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 according to RFC 4648 uses '+' (index 62) and '/' (index 63), and pad characters '='. In URLs, filenames, and HTTP query strings, '+' denotes a space, and '/' acts as a path delimiter, which causes parsing ambiguities or requires percentage escaping. RFC 4648 Section 5 defines URL-safe Base64 (base64url), replacing '+' with '-' (hyphen) and '/' with '_' (underscore), while often omitting trailing '=' padding characters altogether. JWTs (RFC 7519) strictly mandate the URL-safe base64url alphabet without padding.
Can I decode Base64 data containing sensitive passwords or tokens here safely?
Yes, completely. ToolsByUs executes 100% locally within your browser's V8 JavaScript engine. Zero network requests, zero API calls, zero telemetry, and zero server logging occur when you paste or process payloads. You can disconnect your internet connection or inspect your browser's DevTools Network panel to independently verify zero data transmission.
How does the tool automatically detect and inspect JSON Web Tokens (JWT)?
A standard JWT consists of three base64url-encoded parts separated by period '.' delimiters: header, payload, and signature. When you paste an input containing two periods separating base64url strings, the parser decodes the first two segments. If both segments parse into valid JSON containing typical JWT properties such as 'alg', 'typ', or registered claims ('exp', 'sub', 'iat'), the tool immediately displays decoded JSON cards alongside human-readable expiration dates.
How does the binary file download guess MIME types and file extensions?
When decoding Base64 back into raw Uint8Array bytes, the decoder reads the file's 'magic bytes' (initial header signature). For instance, PNG files begin with 0x89 0x50 0x4E 0x47 ('\x89PNG'), JPEG begins with 0xFF 0xD8 0xFF, PDF begins with 0x25 0x50 0x44 0x46 ('%PDF'), and ZIP begins with 0x50 0x4B 0x03 0x04 ('PK'). Based on these magic signatures, the browser synthesizes a typed Blob for direct local download.
Why does my Base64 string fail to decode?
Usually one of three things: it was copied out of an email or a terminal and carries line breaks, it is URL-safe Base64 using - and _ being read as the standard alphabet, or the trailing = padding was trimmed somewhere. This tool handles all three — whitespace is stripped, both alphabets are accepted and missing padding is restored. What no tool can recover from is a string that lost characters in transit.