Free Base58 Encode API Endpoint

Call the free base58 encode api endpoint

The free base58 encode api endpoint takes one path and one POST. Send a JSON body with a data field, then read the encoded string out of the reply.

curl -X POST https://aisenseapi.com/services/v1/base58_encode \
  -H "Content-Type: application/json" \
  -d '{"data":"Hello world"}'

{"base58_encoded_data":"JxF12TrwXzT5jvT"}

A raw body works just as well. The service encodes the request body byte for byte, which is the shorter route when your input is binary or already sitting in a file.

curl -X POST https://aisenseapi.com/services/v1/base58_encode \
  -H "Content-Type: text/plain" \
  -d 'Hello world'

{"base58_encoded_data":"JxF12TrwXzT5jvT"}

Both calls answer with the same string, because both carried the same eleven bytes.

Response field

One field comes back from the free base58 encode api endpoint, and nothing else.

The reply arrives as application/json; charset=utf-8 with HTTP 200. Encoding cannot fail on well-formed input, since every byte sequence has a base58 representation. Rejection happens on the way back instead, which is the job of the Base58 Decode API endpoint.

The alphabet that omits 0, O, I and l

The base58 alphabet is the digits 1 to 9, the uppercase letters without I and O, and the lowercase letters without l. That comes to 58 symbols. Three properties follow from the choice.

1. Nothing looks like anything else

   In most fonts the digit 0 and the letter O are near identical, and a capital I and a lowercase l are frequently the same glyph. Base64 contains all four. Base58 removes the collisions rather than asking a reader to be careful.

2. No punctuation, so selection and wrapping stay safe

   Base64 uses plus, slash and equals. Those need percent-encoding in a URL path, they split a double-click selection in most editors, and a mail client is free to wrap or linkify around them. Base58 output is alphanumeric end to end.

3. The value is a number, not a byte stream

   Base64 slices input into six bit groups. Base58 treats the whole input as one large integer and divides it by 58 repeatedly, because 58 is not a power of two. That is why no padding character exists.

Why Bitcoin addresses and IPFS hashes use it

Those two systems publish short identifiers that people genuinely handle by hand. A wallet address gets photographed, dictated over a phone and typed off a screen. One misread character sends money nowhere, and no recipient ever notices in time.

Base58 was written for exactly that risk. Satoshi Nakamoto picked the alphabet for Bitcoin addresses so no glyph pair could be confused and no punctuation could interfere with a double-click. IPFS then reused it: a CIDv0 hash is a base58 encoded multihash, which is why every one of them starts with Qm.

curl -X POST https://aisenseapi.com/services/v1/base58_encode \
  -H "Content-Type: application/json" \
  -d '{"data":"bitcoin"}'

{"base58_encoded_data":"4jJc4sAwPs"}

Note what base58 does not give you. It carries no checksum of its own. Bitcoin layers Base58Check on top, adding a version byte and four checksum bytes before encoding, and that outer layer is what catches a typo. The free base58 encode api endpoint performs the encoding step only.

Leading zero bytes become the character 1

Treating input as a single number has one consequence worth knowing. A leading zero byte adds nothing to a number, so it would vanish in transit. Base58 handles that by writing one 1, the first symbol in the alphabet, for each leading zero byte.

printf '\x00\x00Hi' | curl -X POST https://aisenseapi.com/services/v1/base58_encode \
  -H "Content-Type: application/octet-stream" --data-binary @-

{"base58_encoded_data":"116Wc"}

Two zero bytes produced two leading ones. This is the same rule that makes a Bitcoin mainnet address begin with a 1, since its version byte is zero. When you round trip fixed width binary, count the leading 1 characters rather than assuming a length.

What base58 costs compared to base64

The free base58 encode api endpoint is not a drop-in upgrade over base64. Two things get worse.

Output runs longer. Each character carries log2(58) bits, roughly 5.86, against exactly 6 for base64, so a long input comes out around two percent bigger. Short inputs can go the other way, since base58 has no padding, which is why eleven bytes of Hello world become fifteen base58 characters against sixteen base64 characters.

Encoding also runs slower. Base64 is bit shifting and finishes in linear time. Base58 is repeated big integer division, which is quadratic in input length. On an address or a hash the difference is invisible. On a megabyte of image data it is not. Push bulk payloads through the Base64 Encode API endpoint and keep base58 for the short, human-facing identifiers it was designed for.

One more caution. This is the Bitcoin alphabet, the common one but not the only one. Ripple and Flickr each defined a different ordering, so check the alphabet before you assume a foreign value is corrupt.

Common uses

Reach for the free base58 encode api endpoint whenever a value has to leave the machine and pass through a person.

Limits on the free base58 encode api endpoint

Your data travels in the POST body rather than the URL, so it never lands in a request path or a server access log. The service-wide limit is 5000 requests per IP per 24 hours, and no key or account is needed anywhere on this base URL.

Other encoders on the same host follow the same rules. Compare them on the Encoding APIs hub, reach for the Base32 Encode API endpoint when a value must survive case folding, or browse every service in the full list of free public REST APIs.

Related APIs