Free Base64 Encode API Endpoint

One call to the free Base64 encode API endpoint

Send a JSON body with a data key. One field comes back.

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

{"base64_encoded_data":"SGVsbG8gd29ybGQ="}

That is the entire contract for the free Base64 encode API endpoint. There is no key to request, no account to create and no signup step. The service-wide limit is 5000 requests per IP per 24 hours.

What Base64 encoding actually does

Base64 is a transport format. It is not compression and it is not encryption. The encoder reads your input three bytes at a time, splits those 24 bits into four groups of six, and maps each group onto one character from a 64 character alphabet: A-Z, a-z, 0-9, + and /.

The benefit is safety. Every output character is ordinary printable ASCII, so the string travels intact through JSON documents, email bodies, HTTP headers, XML attributes, log lines and copy-paste. All of those would mangle raw bytes.

The cost is size. Three bytes in produce four characters out, so the output is roughly 33 percent larger than the input before padding is counted. Budget for that growth wherever you store or forward the result. A 3 MB image arrives back as about 4 MB of text, and a database column sized for the original will not hold it.

That ratio is fixed at four characters for every three bytes, which makes the growth easy to predict. Multiply the input size by four, divide by three, then round up to the next multiple of four. Content never changes the answer, because Base64 does not look at what the bytes mean.

Three ways to send the input

The free Base64 encode API endpoint accepts three shapes of request body. Start with the simplest: a JSON body encodes the value of the data key.

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

{"base64_encoded_data":"SGVsbG8gd29ybGQ="}

A plain text body encodes the body itself, which saves you from escaping quotes and newlines into JSON:

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

{"base64_encoded_data":"SGVsbG8gd29ybGQ="}

A file goes the same way, sent as the raw request body. This example uploads an eight byte file holding nothing but the PNG signature:

curl -X POST https://aisenseapi.com/services/v1/base64_encode \
  -H "Content-Type: application/octet-stream" \
  --data-binary @png-header.bin

{"base64_encoded_data":"iVBORw0KGgo="}

Text is encoded as its UTF-8 bytes, because Base64 is defined over bytes rather than over characters. Sending {"data":"Blåbær"} returns {"base64_encoded_data":"QmzDpWLDpnI="}: six characters in, eight UTF-8 bytes, twelve Base64 characters out.

The response field

The free Base64 encode API endpoint ignores the Accept header entirely. Asking for Accept: text/plain still yields the JSON envelope, so parse the response rather than reading it as a bare string. The decode side behaves differently and does honour Accept.

Watch one detail when you read the raw response text. The JSON serializer escapes the forward slash, so encoding subjects?_d=1 comes back as {"base64_encoded_data":"c3ViamVjdHM\/X2Q9MQ=="}. The backslash belongs to JSON, not to Base64. Any JSON parser hands you c3ViamVjdHM/X2Q9MQ==, which is the correct string. Only naive string slicing sees a problem here.

The transformation is deterministic. Identical input yields an identical string on every call and from every machine, so the output is safe to use as a cache key or to compare directly in a test assertion.

Padding rules and the standard alphabet

The free Base64 encode API endpoint speaks standard Base64 as defined in RFC 4648 section 4. The final two alphabet characters are + and /, and the pad character is =. Base64url, the variant that swaps those for - and _, is not what you get here. Encoding the three bytes FF EF BE proves it: the answer is /+++, which arrives on the wire as {"base64_encoded_data":"\/+++"}.

Padding exists because the encoder works in three byte groups. When the input length is not a multiple of three, the last group is short, and = characters record how much was missing. That is what lets a decoder recover the exact original length:

"a"     becomes  "YQ=="
"ab"    becomes  "YWI="
"abc"   becomes  "YWJj"
"abcd"  becomes  "YWJjZA=="

Output length is therefore always a multiple of four, with zero, one or two trailing = signs. Three is impossible. The encoder never omits padding, even though many decoders tolerate its absence.

That rule doubles as a cheap sanity check. Count the characters in a Base64 string before you decode it. A total that does not divide by four means something was truncated in transit, or a line break was dropped, or the padding was stripped by a tool along the way.

Planning to put the result in a URL? Convert it yourself. Percent-encode +, / and =, or translate + to - and / to _ if the receiver expects base64url. Do the translation in your own code, since this endpoint will not do it for you.

Errors

That is the only failure mode. Every sequence of bytes is encodable, so the free Base64 encode API endpoint has no equivalent of the invalid input error you meet on the decode side.

Decoding lives on its own endpoint

Going the other way is a separate call with its own rules, and it is documented on the Base64 decode API endpoint page. Decoding produces bytes rather than text, so that endpoint reads your Accept header and returns plain text, a typed JSON envelope or the raw bytes as a download. Round trips are exact: a file encoded here and sent straight back decodes byte for byte.

Pick the endpoint by direction. Text or bytes going in means encode. A Base64 string returning to its original form means decode. The two never overlap, and neither one guesses which way you meant.

Other alphabets solve other problems. Reach for the Base32 encode API endpoint when a channel is case insensitive, and for the Base58 encode API endpoint when a human has to read or retype the string. The Encoding APIs hub lists every encode and decode pair, and the full catalogue of free public REST APIs covers hashing, identifiers and the rest.

Common uses

Privacy and limits

Payloads travel in the POST body rather than the URL, so they never appear in request paths. No account exists and no API key is issued. The service-wide limit is 5000 requests per IP per 24 hours.

Related APIs