Encode a string
Call the free Base32 encode API endpoint with one POST request and read the single field that comes back. There is no account, no key and no header beyond the content type.
curl -X POST https://aisenseapi.com/services/v1/base32_encode \
-H "Content-Type: application/json" \
-d '{"data":"Hello world"}'{"base32_encoded_data":"JBSWY3DPEB3W64TMMQ======"}Eleven bytes of input produced eighteen payload characters and six padding characters, twenty-four in total. Input is treated as bytes rather than as text, so UTF-8 round-trips unchanged. Blåbær is eight UTF-8 bytes and encodes to IJWMHJLCYOTHE===.
A plain text body works too and is encoded as sent. That fallback is worth knowing about, because an empty data value drops through to it: posting {"data":""} encodes the JSON text itself instead of returning an empty result. Always send something in the field.
What the free Base32 encode API endpoint returns
| Field | Type | Description |
|---|---|---|
| base32_encoded_data | string | The encoded payload. Uppercase A-Z, the digits 2-7, and trailing = padding that brings the length up to a multiple of eight. |
Only that one field comes back. There is no length, no checksum and no echo of the input, so the response body stays predictable no matter how large the payload is.
Encoding is one half of a pair. Feed the same string to the Base32 decode API endpoint and the original bytes come back as application/octet-stream.
Uppercase A-Z and the digits 2-7
Base32 slices the input into 5-bit groups. Each group selects one symbol from a 32-character table: A through Z, then 2 through 7. That is the RFC 4648 alphabet, and it is the whole reason the format exists.
Nothing in the table is lowercase. A system that uppercases or lowercases the string therefore cannot damage it. The table also skips 0, 1, 8 and 9, which removes the old confusion between 0 and O, and between 1 and I, when somebody reads a code out loud or types it off a printout.
Compare that with the denser option on the Base64 encode API endpoint, which uses both letter cases plus two punctuation marks. Base64 is shorter. But two Base64 strings that differ only in case are two different values, and plenty of systems will not preserve that difference.
Padding to a multiple of 8
Output always arrives in blocks of eight characters. When the input does not divide evenly into five-byte groups, = fills the shortfall. The pattern is fixed, and every row below came from this endpoint:
| Input | Bytes | Output | Padding |
|---|---|---|---|
| A | 1 | IE====== | 6 |
| AB | 2 | IFBA==== | 4 |
| ABC | 3 | IFBEG=== | 3 |
| ABCD | 4 | IFBEGRA= | 1 |
| ABCDE | 5 | IFBEGRCF | 0 |
Six, four, three, one or none. Two, five and seven padding characters never occur in valid Base32. Spotting one of those in a stored string is a strong hint that the value was truncated or trimmed somewhere in transit.
Roughly 60 percent overhead
Eight characters carry five bytes, because a character holds 5 bits and a byte holds 8. Each of those characters still costs a full byte on the wire, so the encoded form is 60 percent larger than the input it represents.
Base64 packs 6 bits per character and grows by only about a third. The gap shows up immediately: Hello world is 24 characters in Base32 and 16 in Base64. Budget for it before pushing large payloads through, and reach for Base64 or the Base58 encode API endpoint when case is preserved end to end.
Short values are where the trade pays off. A 20-byte secret costs you 32 characters instead of 28, which nobody notices, and in exchange the string cannot be broken by case folding.
Nothing about the free Base32 encode API endpoint changes with payload size. The same POST handles a four-byte token and a fifty-kilobyte blob, and the response shape is identical either way. Only the character count moves, and it moves in a straight line: eight characters for every five bytes of input, plus whatever padding the final block needs to reach a multiple of eight.
Why TOTP secrets use Base32
Two-factor enrollment strings in otpauth:// URIs carry the shared secret in Base32, and the free Base32 encode API endpoint produces exactly that shape. The reason is human handling rather than cryptography.
Retyped by hand
People copy a secret off a screen or a printed sheet into an authenticator app. No case to get wrong and no 0, 1, 8 or 9 to misread means fewer failed enrollments.
Scanned and dictated
The same secret gets rendered into a QR code, mailed as text and read aloud on support calls. Uppercase letters and digits survive all three routes.
DNS labels
Resolvers and caches are free to change the case of a hostname, so data carried in a label has to be case-insensitive. Base32 fits the letters-and-digits rule for labels. Base64 does not.
Case-insensitive filesystems
On Windows and on default macOS volumes, two Base64 filenames that differ only in case collide as one file. Base32 names cannot collide that way.
Privacy and limits
Base32 is a representation, not protection. Anyone holding the string can decode it. Never send a live two-factor secret, key or credential to a public endpoint - encode those in your own process.
Payloads travel in the POST body rather than the URL, so they stay out of request paths. The service-wide limit is 5000 requests per IP per 24 hours, with no key and no account behind it.
Every endpoint on the service is listed in the free public REST APIs reference. The encode and decode pairs sit together on the Encoding APIs hub if you want to compare alphabets before you commit to one.