Base32 / Base58 mutual encoding/decoding tool | ZeroTools

This screen is a tool for converting the entered text into two strings, Base32 and Base58, and checking the results side by side.

When you enter text into the input field on the "Encode" tab, the Base32 and Base58 results are displayed in their respective fields.

There is no need to press a conversion button to switch formats; you can compare both from the same input. The result fields are read-only, and you can paste them elsewhere using the copy operation of the required one.

Note that the copy operation is not awaited.

The starting point of the conversion is not the characters themselves entered on the screen, but the UTF-8 byte sequence. The implementation uses the browser's TextEncoder to change the text into bytes, and calls the Base32, then Base58 functions on that byte sequence.

Since the number of bytes used in UTF-8 differs between alphabetic characters like A and characters like 日本語, the output length cannot be determined solely by the number of input characters.

Even if they look the same, adding spaces or line breaks will be converted as a different input. There are no input limits or Web Workers used.

To verify the behavior at hand, first enter Hello. JBSWY3DP will be displayed in the Base32 field, and 9Ajdvzr in the Base58 field.

Next, if you add one character, both results will change, showing that the two methods are not simply changing uppercase and lowercase letters.

If you empty the original input field, the results will also be empty. What is handled here is string notation conversion, not encryption or Bitcoin address creation.

The Base32 output uses a total of 32 characters: uppercase letters A to Z and numbers 2 to 7. Following the method described in RFC 4648, the original 8-bit byte sequence is read in 5-bit units and replaced with characters.

The fractional bits are filled at the end, and = is added if necessary so that the output length is a multiple of 8 characters.

For example, the result of entering the single character f is MY======. The = is not a character included in the original text, but a mark to align the length of the encoded string.

Hello fits within 8 characters, so = is not appended.

During decoding, lowercase letters in the input are treated as uppercase, trailing = and space characters are removed, and the data is read back in 5-bit units.

For this reason, you may be able to restore Base32 with omitted padding or results pasted in lowercase. Note that the Base32 decoder removes trailing = characters first, then converts to uppercase and removes all spaces, so padding placed before trailing spaces might remain and cause an error.

There is no correction to substitute the numbers 0 or 1 for the letters O or I. For example, an input containing 0 as Base32 will result in an error as an excluded character.

If the copied string cannot be read, check if you have mistaken numbers and letters.

The Base32 encoding on this screen produces the RFC 4648 type character set and padding, but the decoding side is not a standards validator.

It does not strictly validate the number of = padding characters, unnecessary trailing bits, or the relationship with the original byte count or incomplete lengths.

Since some string may be displayed even with an incomplete code, do not use it to prove the conformity of data received from the outside, but verify it against the original data or the sender's specifications.

The Base58 field adopts the character set used in Bitcoin-style Base58. It consists of 58 characters excluding the number 0, uppercase O and I, and lowercase l from alphanumeric characters.

Avoiding such confusing characters makes it easier to distinguish when visually checking the displayed strings. The Base58 input field removes all spaces and disallows 0/O/I/l.

However, transcription errors are not automatically detected. Unlike Base32, Base58 does not add = to the end, and converts the input byte sequence from base-256 to base-58 digits.

If the original byte sequence starts with 0-value bytes, the count is represented by 1s lined up at the beginning of the output.

In reverse conversion, zero bytes are restored from the leading 1s, so leading zeros are not dropped. However, the encoding input field on this screen is for UTF-8 text.

There is no function to read arbitrary binary from a file or enter hexadecimal 00 as a 0 byte. Note that even if you enter the character 0, it is the UTF-8 number 0, not a 0 byte.

The "Bitcoin format" here refers to how the characters are assigned. Unlike Base58Check used in Bitcoin addresses and the like, there is no processing to add or verify a checksum.

Even if a Base58-like string can be decoded, it cannot be judged whether it is a valid address or a WIF format secret key. Do not rely solely on this output for the purpose of checking the validity of a remittance destination or key.

Creating or verifying an address requires a dedicated mechanism that can handle the target network and checksum.

To restore the original text, switch to the "Decode" tab, select either Base32 or Base58 with the radio buttons, and paste the code.

The format is not automatically determined. If you select Base32, JBSWY3DP returns to Hello, and if you select Base58, 9Ajdvzr is returned.

If you copy the converted result once and paste it into the reverse conversion, you can verify the input and the restored result yourself.

If you change the input, the result is updated, and if you clear the input, the restored result and errors also disappear.

Check A to Z, 2 to 7, and the trailing padding for Base32, and the respective dedicated character sets for Base58. If there are unusable characters in the chosen format, an error will occur, and previous restored results will disappear.

For example, including the number 0 in Base58 is an invalid character error. If a long code is cut off in the middle or a different method is selected, it will not always necessarily result in an error.

Since "being able to read as characters" alone does not guarantee the correctness of the original data in either case, it is important to compare the displayed text with the expected original data.

The decode function first returns a byte sequence, and then TextDecoder displays it as a UTF-8 string. Even if the code is valid, if the original bytes were not valid UTF-8, the unreadable parts may appear as the replacement character U+FFFD, because TextDecoder is non-fatal.

This is a clue that there were bytes that could not be textified, not a symbol indicating a Base58Check verification failure. There is no feature to accurately restore and save arbitrary binary content like images or compressed files from this field.

Base32 and Base58 are encoding formats for representing byte sequences using only limited characters. Because anyone who knows the method can revert them back to the original, it is different from encryption which hides the contents.

Converting passwords or secret keys to Base58 does not mean third parties cannot read them. Do not assume it is safe to send private information just because it has "changed into alphanumeric characters." Generating random passwords, encryption, and calculating hash values are also not features of this page.

The conversion calculations on this screen are performed by JavaScript within the component inside the browser. However, this alone does not guarantee that the site has zero communications, as site delivery and analytics may still occur.

Furthermore, it does not guarantee that inputs on the device are immediately deleted, or that the clipboard history is not kept. If you copy the results, the paste destination and the device's clipboard functions are also included in the scope of information management.

Avoid entering secret keys, login passwords, or API keys as examples, and check the mechanism with short texts that are safe to publish.

If you need to hide the contents, adding characters before or after Base32/Base58 is not a substitute. Choose appropriate encryption for your purpose separately, and consider including how to store keys and passwords.

Conversely, if you simply want to change the notation to a standard character set, encryption operations are unnecessary. Clarifying first whether what you need is "conversion to readable characters" or "processing to protect secrets" prevents misuse.

For brief behavioral checks, f and Hello are useful. With f, you can see the Base32 MY====== to check the meaning of padding.

With Hello, you can compare Base32 JBSWY3DP and Base58 9Ajdvzr to confirm that Base58 includes lowercase letters while Base32 does not.

By reverting each result on the decode tab, you can verify on the same screen whether the selected format and the original text match.

If the results differ, check the differences in the original input, such as leading or trailing spaces, line breaks, and uppercase/lowercase letters.

Testing specifications using Base32's fixed character set and visually verifying the Base58 notation of the Bitcoin method serve different purposes.

If you want to convert a Base32 code to Base58, the procedure would be to decode that code as Base32 and input the restored UTF-8 text into the encode field.

There is no dedicated button to directly convert any arbitrary Base32 code to Base58. If the original byte sequence is something other than text, this procedure could change the content.

Supported are the encoding of UTF-8 text and the display from code back to UTF-8 text. It does not support arbitrary binary files, hexadecimal inputs, generating/verifying Bitcoin addresses or WIFs, creating TOTP secret keys, or Base58Check checksum additions/verifications.

Base32 is also not a strict standard conformity check for received codes. By confirming beforehand whether the target data is truly text, which method it was created with, and whether a checksum is required, you can avoid confusing a result appearing on the screen with the data being correct.