Free Base64 Decode API Endpoint

Call the free Base64 decode API endpoint

Most callers want readable text back, so the free Base64 decode API endpoint needs one extra header to say so. Send the string in a JSON body under a data key and ask for text/plain:

curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: application/json" \
  -H "Accept: text/plain" \
  -d '{"data":"SGVsbG8gd29ybGQ="}'

Hello world

That is the whole happy path. Post the string, ask for text, read the body. There is no account, no API key and no signup step. The sections below cover the two other response shapes, the alphabet rules that decide what counts as valid input, and the one error you are likely to meet.

Going the other direction is a separate call. See the Base64 encode API endpoint for turning bytes into a Base64 string.

Three response shapes, one Accept header

Decoding produces bytes, and bytes can be anything: a sentence, a JSON document, a gzip stream, half a JPEG. No single response format serves all of those honestly. So the free Base64 decode API endpoint reads your Accept header and picks one of three modes. Callers who send no Accept header and expect text are the most common source of confusion here.

1. Accept: text/plain returns the decoded text

The body is the decoded text and nothing else, served as text/plain; charset=utf-8. No envelope, no quoting, no second decode step in your code. Use this whenever you know the payload is text.

curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: application/json" \
  -H "Accept: text/plain" \
  -d '{"data":"QmzDpWLDpnI="}'

Blåbær

2. Accept: application/json returns a typed envelope

If the decoded bytes parse as JSON, you get them back as real JSON, already parsed, under type: json:

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

{"type":"json","decoded_data":{"ok":true}}

If they do not parse as JSON, the bytes come back still Base64 wrapped, labelled so you know it:

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

{"type":"binary","encoding":"base64","decoded_data":"SGVsbG8gd29ybGQ="}

That looks like a no-op, because decoded_data is byte for byte what you sent. It is not. The service decoded your input, found the result was not JSON, and re-encoded the same bytes so they could cross the wire without damage. A JSON string holds Unicode characters, not arbitrary bytes, and anything that tried to squeeze raw bytes into one would have to guess an encoding and silently corrupt whatever did not fit. Branch on type rather than assuming decoded_data is readable.

3. No Accept header returns a download

With no Accept header, with */*, or with application/octet-stream, the response body is the decoded bytes themselves:

curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: application/json" \
  -d '{"data":"SGVsbG8gd29ybGQ="}' \
  -D - -o decoded.bin

HTTP/2 200
server: AISENSE
content-type: application/octet-stream
content-disposition: attachment; filename="decoded_data.bin"
content-length: 11

This is the mode for files. Add -o output.bin and the bytes land on disk unchanged. A browser follows the Content-Disposition header and saves them as decoded_data.bin. Round trips are exact, so an image encoded and sent straight back is byte identical to the original.

Accept lists are scanned left to right, and the first supported type wins. Accept: text/plain, */* gives you text. A browser default of text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 ends in a download, because */* is the first entry the service recognises. Only a list with no supported entry at all, such as a bare Accept: text/html, is rejected.

Sending the input

A JSON body with a non-empty data string is decoded. Otherwise the raw request body is treated as the Base64 payload, which lets you skip the envelope entirely:

curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: text/plain" \
  -H "Accept: text/plain" \
  --data-binary 'SGVsbG8gd29ybGQ='

Hello world

The free Base64 decode API endpoint speaks standard Base64 from RFC 4648 section 4, not the URL-safe variant. The alphabet ends in + and /, and padding is =. A base64url string is rejected: Pz8_Pw== returns HTTP 400. Translate - to + and _ to / first.

The decoder is otherwise forgiving. Trailing padding is optional, so SGVsbG8gd29ybGQ still decodes to Hello world. Whitespace inside the input is ignored, which means Base64 wrapped at 64 columns by a tool like openssl base64 can be posted with its line breaks intact. Characters outside the alphabet are the one thing that is not tolerated.

The same three-mode pattern appears on the Base32 decode API endpoint and the Base58 decode API endpoint, so code written against one moves across with only the path changed.

Errors

Common uses

Privacy and limits

Payloads travel in the POST body rather than the URL, so they never appear in request paths. There is no account and no API key, and the service-wide limit is 5000 requests per IP per 24 hours. Full terms and the rest of the catalogue sit on the free public REST APIs reference.

Related APIs