About Number Base & Radix Converter
Number Base & Radix Converter does two related but distinct jobs. In numeric mode it rewrites an integer from one base between 2 and 36 into another, using arbitrary-precision arithmetic so a 40-digit value survives intact. In RFC mode it encodes and decodes text as RFC 4648 Base32 or Base64, or through a custom alphabet you supply, which is how Base58 and Base62 are reached.
Base conversion and byte encoding look alike and are not the same operation. Converting a base takes one integer and rewrites its digits: the value is unchanged and only the notation moves. Encoding takes a sequence of bytes — text, a key, a hash — and regroups the bits into an alphabet so they survive a channel that would mangle them. The first is arithmetic, the second is transport. Mixing them up produces results that are syntactically plausible and semantically meaningless, which is the hardest kind of bug to spot.
How to use this developer tool
- Choose numeric base mode for an integer, or RFC / custom mode for text and byte data.
- In numeric mode, set the source and target base — each between 2 and 36 — and enter the value. Digits are read case-insensitively and the result is always uppercase.
- Use the swap button to reverse the conversion: it exchanges the two bases and moves the result into the input, which makes a round-trip check a single click.
- In RFC mode, pick a direction and a method: RFC 4648 Base32, RFC 4648 Base64, or a custom alphabet you type in. The field hint shows how many characters your alphabet has, which is the base you are actually working in.
- Read the result against the alphabet you expected. A value rejected as invalid almost always contains a character the selected base does not define, such as an 8 in octal or a lowercase l in Base58.
Worked example: the same four characters, two unrelated results
The value 2026 run through both modes. The outputs look equally plausible and describe completely different things.
Numeric base 2026, from base 10, to base 16
RFC / custom 2026, encode, RFC 4648 Base32Numeric base 7EA
RFC / custom GIYDENQ=7EA is the integer two thousand and twenty-six written in base 16: 7 x 256 + 14 x 16 + 10 = 2026. GIYDENQ= is not a number at all. It is the four ASCII bytes 0x32 0x30 0x32 0x36 — the characters "2026" — regrouped into five-bit chunks and padded out to eight characters. Decode it and you get the text back, not the value.
Digit alphabets by base
Numeric mode covers bases 2 to 36 using 0-9 then A-Z, the alphabet JavaScript's own toString uses. Bases 58, 62 and 64 are byte encodings rather than positional notations for a number, and are reached through RFC mode.
| Base | Digits | Where it lives here |
|---|---|---|
| 2 binary | 0 1 | Numeric mode |
| 8 octal | 0-7 | Numeric mode |
| 10 decimal | 0-9 | Numeric mode |
| 16 hexadecimal | 0-9 A-F | Numeric mode; input is case-insensitive, output is uppercase |
| 32 numeric | 0-9 A-V | Numeric mode. This is not RFC 4648 Base32 and the two never agree |
| 32 RFC 4648 | A-Z 2-7, padded with = | RFC mode. Omits 0, 1, 8 and 9 so the alphabet is hard to misread aloud |
| 36 | 0-9 A-Z | Numeric mode, and its maximum |
| 58 Bitcoin | 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz | RFC mode with a custom alphabet. Omits 0, O, I and l |
| 62 | 0-9 A-Z a-z | RFC mode; the custom alphabet the field is pre-filled with |
| 64 RFC 4648 | A-Z a-z 0-9 + /, padded with = | RFC mode |
| 64 URL-safe | A-Z a-z 0-9 - _, usually unpadded | Not offered here; use the Base64 Encoder & Decoder |
Troubleshooting
A negative number or a decimal is rejected.
Why it happens Numeric mode reads a sequence of digits from the source alphabet and nothing else. A minus sign, a decimal point, a thousands separator, whitespace and an 0x prefix are all characters with no digit value.
Fix Convert the magnitude and reattach the sign yourself. For a fraction, convert the integer and fractional parts separately, and remember that most decimal fractions have no finite binary expansion, so 0.1 in base 10 is not exact in base 2.
Leading zeros disappear.
Why it happens The tool converts a value, not a fixed-width field. 007EA and 7EA are the same integer, so both convert to 2026 in base 10 and both come back as 7EA.
Fix Pad after converting, to whatever width the destination needs. If the leading zeros are significant — a zero-padded account number, a fixed-width register dump — you are handling an identifier rather than a number, and it should stay a string.
A Base58 string will not decode, or decodes to something else.
Why it happens Case. Numeric mode lowercases its input and RFC 4648 Base32 decoding uppercases its input, so both are case-insensitive. Base64 and every custom alphabet are case-sensitive, and Base58 in particular uses both cases while deliberately omitting 0, O, I and l so those glyphs cannot be confused.
Fix Paste Base58 and Base64 exactly as received, without letting an editor or a chat client fix the capitalisation. If the string contains 0, O, I or l, it is not Bitcoin-style Base58 and you have the wrong alphabet.
Custom-alphabet output does not match another Base58 implementation.
Why it happens The custom-alphabet mode treats the bytes as one big integer and writes it out in the chosen base. Bitcoin-style Base58 does the same, then adds one leading alphabet character per leading zero byte. This tool does not, so bytes 00 00 01 02 03 encode to Ldp and decode back as 01 02 03 — the zero bytes are gone.
Fix Use this mode for short identifiers and vanity encodings where no leading zero bytes occur. For addresses, keys or anything Base58Check, use a library that implements the leading-zero rule and the checksum.
When this tool is the right choice
- Reading a hexadecimal value out of a register dump, a colour code or a stack trace as an ordinary decimal number.
- Converting a permissions mask between octal and binary while reasoning about a chmod or an ACL.
- Working with integers far beyond 64 bits, since the conversion uses arbitrary-precision arithmetic rather than floating point.
- Generating a short identifier in Base58 or Base62 from a known value, and checking it decodes back to the same bytes.
When to use something else
- Routine Base64 work, especially URL-safe tokens. The Base64 Encoder & Decoder handles the - and _ alphabet and unpadded input, which the RFC 4648 Base64 option here does not.
- Turning an image into a data URL. The Base64 Image Encoder & Decoder is built for binary files and previews the result.
- Fingerprinting, verifying or protecting data. Encoding is reversible by design; use the Hash & Checksum Generator for integrity, and real encryption for confidentiality.
Privacy and data handling
Every conversion is computed in this browser tab with BigInt arithmetic and the browser's own UTF-8 encoder; nothing is transmitted and nothing is stored. Be clear with yourself about what encoding is: Base32, Base64 and Base58 are fully reversible in one step by anyone who sees the output. They protect data from a channel, never from a reader.
Related developer tools
Frequently asked questions
Is Base64 a number base?
Not in the sense numeric mode means. Base 16 rewrites one integer's digits, while Base64 regroups a byte stream six bits at a time into a 64-character alphabet and pads the result. The word base is doing two different jobs, which is why the two modes are kept apart here.
Why does numeric mode stop at base 36?
Because 10 digits plus 26 Latin letters is 36 symbols, and beyond that there is no convention everyone agrees on — Base58, Base62 and Base64 all choose different alphabets and orderings. Above 36 you must state the alphabet explicitly, which is what the custom-alphabet field is for.
How large a number can I convert?
As large as you like. The conversion uses BigInt, so a 200-digit value converts exactly. Floating-point tools lose precision above 2^53 - 1 and will silently round a 19-digit identifier; this one does not.
Why is my base 32 result different from the RFC 4648 one?
They are different systems that share a number. Numeric base 32 uses 0-9 then A-V and represents an integer; RFC 4648 Base32 uses A-Z then 2-7, represents bytes, and pads with =. Neither is wrong, but they will never produce the same string.
Does the custom alphabet have any rules?
Two: at least two characters, and no duplicates, since a repeated character would make decoding ambiguous. Order matters as much as contents — the first character is the digit zero — so the same letters in a different order produce entirely different output.
Can I use this to hide a value?
No, and it is worth being blunt. Base32, Base64 and Base58 are public, documented and reversible in one step by anyone. If a value needs to stay secret, encrypt it; if it needs to be tamper-evident, sign or hash it.