BINARY / TEXT / INTEROPERABILITY
ORIGINS / STANDARDS / OPERATIONS
早期邮件和文本链路并不能可靠承载任意二进制。MIME 在 1990 年代规范了 Base64 传输编码；RFC 4648 在 2006 年统一 Base16、Base32、Base64 及其变体的字母表、填充与规范编码。三个字节拆成四个 6 位符号，因此 Base64 通常增加约三分之一体积；它不是压缩。
编码不需要秘密，任何人都能还原；它不是加密、哈希、签名或脱敏。先把文本确定为 UTF-8 字节，再选择表示格式。汉字、emoji、行尾和 Unicode 规范化都会影响字节，本页不自动 trim 或规范化。无法作为 UTF-8 的二进制应查看 Hex，而不是强行显示成文本。
规范解码还应检查未使用的填充位；能解出相同字节，不代表原字符串是合法的规范表示。本页拒绝混合字母表、无效填充位与隐式空白，Base64/Base64url 支持规范的带填充或无填充形式。
标准 Base64 使用 +、/ 和 =；Base64url 把 +、/ 换为 -、_，便于 URL、文件名及协议字段。省略 = 必须由协议约定，JOSE/JWS 的 Base64url 使用无填充形式。它与 encodeURIComponent 的百分号编码是两件事，application/x-www-form-urlencoded 还可能把 + 当空格。
JWT 常见的三个部分是 Base64url 表示，但解出 header/payload 不等于验证签名、发行者、受众或有效期。JWE 则是不同的加密封装。JWK 中 RSA 整数和 EC/OKP 字段也使用 Base64url；RSA 的无符号整数规则、EC 坐标的固定宽度与前导零不能混用。
PEM 是带 BEGIN/END 标签和换行规则的 Base64 文本装甲；DER 是 ASN.1 的二进制编码。本页只转换原始字节，不把裸 Base64 自动识别为证书、PKCS#8 或 JWK。
Bitcoin 生态推广的 Base58 去掉 0、O、I、l 等易混淆字符。本页使用 Bitcoin 字母表，大小写敏感，前导零字节编码为前导 1。Flickr、XRP 等字母表并不相同；Base58 本身没有校验和，也不自动携带网络或类型信息。
Base58Check 在数据后追加双 SHA-256 的前四字节，再做 Base58。常见协议还会在数据前放版本或前缀；本页要求你自己提供这些字节，解码会验证并移除校验和，保留完整前缀与载荷。校验和主要检测差错，攻击者也能重算，不提供认证或保密。
Bech32（BIP 173，2017）把 HRP、数据和六个校验字符组合；Bech32m（BIP 350，2021）改变校验常量。两者不可互换，禁止大小写混合。本页采用通用 bytes → 5-bit words 容器，最长 90 字符，不是 Bitcoin 地址解析器：SegWit 还要检查见证版本、程序长度、网络 HRP 与校验类型，不能只看校验通过。
| 格式 | 表示与开销 | 典型用途 / 易错点 |
|---|---|---|
| Hex / Base16 | 每字节 2 个字符；本页输出大写 | 密钥、指纹、调试；前导零不可丢，不把十六进制字节当口令文本。 |
| Base32 | A–Z、2–7；5 字节 → 8 字符 | TOTP secret 常用，不是一次性验证码。Crockford 与 z-base-32 是不同格式，不能混解。 |
| Base32hex | 0–9、A–V；与 Base32 同样开销 | 排序友好的字母表；用于 DNSSEC NSEC3 等场景，不等于 Hex。 |
| Base64 / Base64url | 3 字节 → 4 字符，尾部可能有 = | MIME、PEM、JOSE、JWK；字母表、填充、协议和签名验证须分别约定。 |
| Base58 / Base58Check | 约 1.37 字符/字节；Check 另加 4 字节校验 | 可读标识和部分链地址；字母表、前导零、版本前缀与校验和都要一致。 |
| Bech32 / Bech32m | HRP + 1 + 5-bit 数据 + 6 字符校验 | 人类可读前缀与差错检测；本页仅通用字节容器，不验证地址或助记词语义。 |
为每个字段固定原始类型、字节序、编码、大小写、填充与最大长度。密钥 ID 是标识，不应包含可恢复的秘密；随机 token 的熵来自随机字节，不来自 Base64 或 Base58。规范化应在协议约定的边界完成，签名验证必须使用协议规定的精确字节，不能先随意重排 JSON 或重新编码再验签。
Base58 类仅限 8 KiB 输入以约束大整数转换成本；其他格式输入最多 1 MiB，解码文本最多 2 MiB。Bech32 类最长 90 字符。所有转换在当前本地 Worker 完成，页面不保存输入、不联网，不把校验通过解释成来源可信。
| 标准入口 | 范围 |
|---|---|
| RFC 4648 / RFC 2045 | Base-N 字母表与规范编码、MIME 传输编码。 |
| RFC 7515 / RFC 7517 / RFC 7468 | JWS、JWK 与 PKIX 文本装甲；解码不替代验证。 |
| BIP 173 / BIP 350 | Bech32 与 Bech32m；地址协议有额外语义约束。 |
Early email and text links could not reliably carry arbitrary bytes. MIME standardized Base64 transfer encoding in the 1990s; RFC 4648 brought Base16, Base32, Base64 and their variants together in 2006, specifying alphabets, padding and canonical forms. Base64 turns three bytes into four six-bit symbols, usually adding about a third to the size. It is not compression.
Encoding needs no secret. Anyone can reverse it; it is not encryption, hashing, signing or redaction. Decide which bytes the text represents before choosing an encoding. Chinese characters, emoji, line endings and Unicode normalization all matter. This page neither trims nor normalizes input. If binary data is not valid UTF-8, inspect it as Hex rather than forcing a text interpretation.
A decoder must also check unused padding bits. Producing the same bytes does not make every spelling canonical. Mixed alphabets, invalid padding bits and implicit whitespace are rejected here. Base64 and Base64url accept canonical padded or unpadded forms.
Base64 uses +, / and =. Base64url replaces + and / with - and _, making it easier to use in URLs, filenames and protocol fields. Whether = may be omitted is a protocol decision; JOSE/JWS uses unpadded Base64url. This is different from encodeURIComponent's percent encoding. Form encoding can also interpret + as a space.
A typical JWT has three Base64url parts, but decoding its header or payload verifies neither its signature nor its issuer, audience or expiry. JWE is a separate encrypted format. JWK uses Base64url too, with different rules for RSA unsigned integers and fixed-width EC/OKP fields. Leading zeros and widths cannot be treated interchangeably.
PEM adds BEGIN/END labels and line-break rules around Base64 text; DER is a binary ASN.1 encoding. This tool converts raw bytes. It does not identify a bare Base64 value as a certificate, PKCS#8 key or JWK.
Bitcoin's Base58 alphabet leaves out easily confused characters such as 0, O, I and l. This page uses that case-sensitive alphabet and preserves leading zero bytes as leading 1s. Flickr and XRP use different alphabets. Plain Base58 includes neither a checksum nor an automatic network or type identifier.
Base58Check appends the first four bytes of a double SHA-256 hash before Base58 encoding. Protocols often add version or prefix bytes first; you must supply those bytes yourself. Decoding checks and removes the checksum while retaining the full prefix and payload. A checksum detects errors, but an attacker can recompute it. It provides neither authentication nor confidentiality.
Bech32 (BIP 173, 2017) combines an HRP, data and six checksum characters. Bech32m (BIP 350, 2021) changes the checksum constant; the two are not interchangeable, and mixed case is forbidden. This page uses a generic bytes-to-five-bit-words container with a 90-character limit. It is not a Bitcoin address parser. SegWit also needs witness-version, program-length, network-HRP and checksum-type checks.
| Standards | Representation and common mistakes |
|---|---|
| Hex / Base16 | Two characters per byte; uppercase output here. Preserve leading zeros. Hex key bytes are not passphrase text. |
| Base32 | A-Z and 2-7; five bytes become eight characters. Common for TOTP secrets, not the one-time codes themselves. Crockford and z-base-32 are different encodings. |
| Base32hex | 0-9 and A-V, with the same overhead as Base32. Used in contexts such as DNSSEC NSEC3; it is not Hex. |
| Base64 / Base64url | Three bytes become four characters, sometimes followed by =. MIME, PEM, JOSE and JWK have their own alphabet, padding and verification rules. |
| Base58 / Base58Check | About 1.37 characters per byte; Check adds four checksum bytes. Agree on the alphabet, leading zeros, version prefix and checksum. |
| Bech32 / Bech32m | HRP + separator 1 + five-bit data + six checksum characters. This tool checks the generic byte container, not address or mnemonic semantics. |
Specify each field's raw type, byte order, encoding, case, padding and maximum length. A key ID is an identifier, not a place for recoverable secrets. A random token gets its entropy from random bytes, not Base64 or Base58. Normalize only at a boundary defined by the protocol. Signature verification must use the protocol's exact bytes, not JSON that has been casually reordered or re-encoded.
Base58 input is limited to 8 KiB to bound big-integer conversion costs. Other formats allow up to 1 MiB of bytes and 2 MiB of encoded text; Bech32 variants are limited to 90 characters. Conversion runs in a local Worker without network requests or input storage. A valid checksum is not evidence of a trusted source.
| Standards | Scope |
|---|---|
| RFC 4648 / RFC 2045 | Base-N alphabets, canonical encodings and MIME transfer encoding. |
| RFC 7515 / RFC 7517 / RFC 7468 | JWS, JWK and PKIX text armor. Decoding does not replace verification. |
| BIP 173 / BIP 350 | Bech32 and Bech32m. Address protocols add semantic requirements. |