What "base conversion" means
A base (or radix) is the number of distinct digits a positional number system uses before it carries over to the next column. Decimal is base 10 because it has ten digits, 0 through 9. Binary is base 2, using only 0 and 1. Hexadecimal is base 16. None of these represent different quantities — the number of pebbles in a pile doesn't change depending on how you write it down — they're just different notations for the same value. Converting between bases means re-expressing the same underlying quantity using a different digit alphabet and a different set of positional weights.
The tools in this section all convert to or from hexadecimal, since hex is the format most often used to represent raw bytes and machine-level values in software development. Each one targets a specific other base or a specific representation convention, because the algorithm and the practical use case differ enough between them that a single generic "convert any base to any base" tool would hide more than it explains.
Numeral bases versus byte encodings
It's worth separating two things that get lumped together under "base conversion." Binary, octal, base12, and base36 are true positional numeral systems — they represent one integer using a different digit alphabet, and the math is the same weighted-sum arithmetic used for hex-to-decimal conversion, just with a different radix. Base32 and Base64, on the other hand, are byte-to-text encoding schemes defined by RFC 4648. They don't reinterpret a number in a new base; they take a sequence of raw bytes and encode each group of bits into a printable character from a fixed alphabet, primarily so binary data can be safely embedded in text formats like JSON, URLs, or email. The practical effect is that Base64 of a hex string depends on the exact byte boundaries (padding matters), while base36 of the same digits is just the number in a different radix, with no concept of byte alignment at all.
Signed integers, negative numbers, and byte order
Three tools here deal with representation rather than radix. The signed integer converter interprets a hex bit pattern as a two's complement number at a chosen width (8, 16, 32, or 64 bits) — the same interpretation a CPU applies to a signed register. Thenegative decimal tool instead uses sign-magnitude notation, a plain minus sign in front of the hex value, which is how people write negative numbers by hand but not how they're stored in memory. And thelittle-endian tool addresses a different problem entirely: byte order. A multi-byte value can be stored most-significant-byte-first (big-endian) or least-significant-byte-first (little-endian, used by x86 and most consumer hardware), and reading a hex dump correctly depends on knowing which convention produced it.
Why this matters in practice
Base conversion comes up constantly in low-level and systems-adjacent work: reading a hex dump of a binary file, decoding a protocol header, generating a short identifier from a large integer (base36 and base62 are common for compact IDs), or figuring out why a value read from a network packet looks wrong until you realize it's little-endian. Octal specifically still appears in Unix file permission notation (chmod 755) and in some legacy embedded systems. Base32 shows up in TOTP two-factor secrets and DNS-safe encodings, because its alphabet avoids characters that are easy to misread (like 0 and O, or 1 and l) or that need escaping in case-insensitive contexts.
The same value, one number per base
A concrete comparison makes the relationship between these bases easier to see than the definitions alone. Take the decimal value 255, the largest number that fits in a single byte. In binary it's11111111 — eight digits, one per bit. In octal it's 377. In hexadecimal it'sFF, exactly two digits, which is the whole reason hex is preferred for byte-level work: the digit count lines up with byte boundaries in a way octal and decimal don't. In base36 the same value is73, and in base12 it's 193. None of these are more "correct" than another; they're just different alphabets for writing down the number 255.
Byte-oriented encodings behave differently from that pattern. Encode the single byte 0xFF in Base64 and the result is /w== — padded to four characters because Base64 always groups its output into four-character blocks regardless of how many bits the input actually needed. That padding behavior, not just the numeric value, is often the detail that trips people up when they're expecting Base64 to behave like a numeral system.
How to use these tools
Each converter on this page works the same way: type a value on either side and the other side updates immediately, so there's no separate "convert" step. Every tool also has a batch mode below the live converter — paste a list of values, one per line or comma-separated, and get a full table of results you can export as a CSV file, useful for converting a whole log file's worth of addresses or IDs at once rather than one at a time.