01
Choose what the input means
In encode mode, 41 as UTF-8 is two bytes; 41 as hex is the single byte for A. Decimal byte input accepts values from 0 to 255 separated by ASCII whitespace, without array brackets or commas.
Encoding and escaping
Base encoderBase16 / 32 / 58 / 85
Select the byte representation and a named alphabet before encoding or decoding.
Base encoder
Input
Conversion stays in this browser; input is not uploaded.
Result
Encoding options
UTF-8 text, hex byte pairs, or decimal bytes 0–255 separated by spaces. No 0x prefixes, commas or brackets.
Base32 requires uppercase. Base58 has no checksum. Z85 requires complete groups of 4 bytes / 5 characters.
Input: 65,536 UTF-16 units; batch: 1,000 physical lines. Per item: 65,536 bytes, or 4,096 bytes / 5,600 characters for Base58. Report: 2,000,000 characters; execution: 2 seconds.
Enter text or load an example. Empty input converts to empty output.
A Base encoder helps when a token is valid in one library but fails in another. The same bytes can have different printable representations: changing an alphabet changes the symbols, while converting a number is a different task. Start with the protocol or library that produced your value.
This workspace combines a Base32 encoder, a Base58 decoder and an Ascii85 converter with byte inspection. Text enters as UTF-8; hex bytes and decimal byte lists let you work with binary values that cannot be read as text.
Why use this Base encoder
Keep the alphabet attached to the result
The Base encoder names Bitcoin and Flickr separately, and distinguishes Ascii85, Git b85 and Z85. The report includes the selected variant, so the next person can reproduce the conversion instead of guessing from a string that fits several alphabets.
Keep failed batch items visible
A line containing a bad character does not erase the other results. Each record keeps its original line number, output and error. JSON also keeps a decoded line break inside its own value, so two records cannot accidentally become three.
Check representation, grouping and result boundaries
02
Match the receiving implementation
Base32 padding affects encoding only. Decoding accepts correct padding or none, but still checks uppercase letters and unused bits. Ascii85 framing is separate from Git b85; Z85 needs four-byte groups and never adds zeros for you.
03
Inspect before reversing
Open byte details to compare hex and decimal values. Turn off automatic conversion to use Ctrl/Cmd + Enter. Reverse previews the replacement and changes direction only after Apply; Undo restores the previous input and result together.
Eight alphabets with explicit byte handling
Base16 and two Base32 alphabets
Base16 produces two uppercase hexadecimal digits per byte and accepts lowercase hex on decode. RFC 4648 Base32 uses A–Z and 2–7; base32hex uses 0–9 and A–V. The latter is a different alphabet, not hex input with a Base32 label.
Two Base58 orders
Bitcoin and Flickr use the same set of symbols in different orders. Each leading zero byte is retained as a leading 1. The converter works on bytes, so entering a decimal identifier as text does not calculate that identifier’s short link.
Three distinct Base85 formats
Ascii85 supports z for a full zero block and optional paired Adobe markers. Git b85 uses the RFC 1924 alphabet with four-byte blocks. Z85 uses ZeroMQ’s alphabet and requires complete groups. Selecting a variant selects its algorithm too.
Readable text and exact byte views
Every successful byte conversion exposes a byte count, spaced hex and decimal bytes. UTF-8 decoding is fatal: invalid bytes remain inspectable and never silently become replacement characters. Batch JSON retains these diagnostics alongside each source line.
Accepted forms and deliberate limits
- No alphabet guessing or character repair
- Base32 decoding requires uppercase and does not map O to 0 or I to 1. Partial padding and nonzero trailing pad bits fail. Decode can ignore only ASCII space, tab, CR and LF; other whitespace and a pasted BOM are rejected. Text encoding keeps its spaces and line endings.
- Bytes are not checksummed addresses
- The Bitcoin alphabet does not add or validate Base58Check checksums, network prefixes, WIF keys or wallet addresses. Flickr alphabet support does not convert photo IDs to short URLs. There are no custom alphabets, Crockford, Ripple or arbitrary-radix integer operations.
- Base85 boundaries stay visible
- Ascii85 accepts raw data or a complete <~ ~> pair, rejects btoa’s y abbreviation and does not parse PDF streams. Git b85 is not RFC 1924’s whole-IPv6 integer encoding. Z85 rejects incomplete groups instead of adding or removing zeros. Overflowing five-character words fail.
- Batch lines are separate byte values
- CR, LF and CRLF split batch records; fully empty lines are skipped while space-only values remain. Per-row errors stay in the JSON report. Single-value mode treats line endings as data. Batch output cannot be used by the reverse action because the report is not an encoded stream.
- Limits bound conversion and export
- Input is limited to 65,536 UTF-16 units and batches to 1,000 physical lines, including empty ones. Each item permits 65,536 bytes; Base58 permits 4,096 bytes or 5,600 encoded characters. A complete report over 2,000,000 characters or a task over two seconds fails as a whole.
- Text uses UTF-8; files stay outside this page
- There is no file import, URL fetching, PDF extraction or legacy character-set detection. Invalid UTF-8 produces an error while hex and decimal remain available. Valid BOM characters and combining sequences are retained. The preview shows up to 20,000 characters or 50 rows at a time; exports include complete fresh results.
Base encoder questions
Why do I get an Incorrect Padding error while trying to decode my Base32 string?
The encoded body must have a valid Base32 length. For example, MY====== and MY both represent f, while MY= has incomplete padding. This tool accepts either exact padding or no padding and also rejects nonzero unused bits. Check that your source uses RFC 4648 Base32 rather than base32hex or Crockford.
What are the differences between the various Python base 85 functions?
They differ in alphabet, framing and short groups. Choose Ascii85 for the ! through u alphabet, Git b85 for Python’s b85encode-style blocks, or Z85 for ZeroMQ. Ascii85’s z abbreviation and Adobe markers are not valid shortcuts in the other variants.
What does normalize leading zeros mean in Base58 encoding?
A leading 1 represents each leading zero byte in both supported Base58 alphabets. A byte sequence 00 00 01 therefore encodes as 112. Converting only the numeric magnitude would lose those leading bytes; this converter preserves the byte sequence.
How can I make Base32 work with the international alphabet and special characters?
Convert characters to UTF-8 bytes before encoding. Accented text, Chinese and emoji work without splitting Unicode characters into single-byte values. On decode, choose UTF-8 only when the original bytes really represent UTF-8; otherwise use hex or decimal to inspect them.
Can Base85 or Ascii85 encoding be identified automatically?
Not reliably. The alphabets overlap, so a string can be accepted by more than one decoder and produce different bytes. This page requires an explicit variant. Consult the source protocol or library, then check the decoded byte count and a known sample.
How do I Base58Check encode or decode an address?
Base58Check adds version data and a checksum around a byte payload. This page provides raw Base58 encoding and decoding only; it does not create or validate that envelope. A result that decodes successfully is not proof that a wallet address or key is valid.
Found an encoding edge case?
Check a value against its source
Use the Base encoder with a short known value, confirm its exact alphabet and byte representation, then expand to a batch once the result matches.