Turn Base64 file sources into direct URLs
The file starts as an encoded string. The next service wants a URL. Decode the Base64 into bytes, preserve filename and content type, upload with multipart, then map the returned file URL.
- Reviewed by
- GetFileURL technical team
- Updated
- File
- image.png
- Content type
- image/png, application/pdf, text/plain, and other allowed file types
- Not for
- a reason to Base64-encode large files when multipart upload is available
What this page answers
Use Base64 only as a source format when a tool gives you an encoded string. Decode it first, then use multipart upload when calling GetFileURL.
- Reviewed by
- GetFileURL technical team
- Last updated
Base64 needs decoding, a filename, and a content type to become a useful URL.
A raw encoded string does not tell the next API what the file is. Decode it into bytes, attach the correct filename and content type, then upload those bytes as the multipart `file` field.
Decode bytes
Turn the Base64 string into a Blob, File, or server buffer before calling `POST /v1/files`.
filename
Provide the extension and human-readable name the destination should see.
content_type
Set the MIME type so OCR, AI, document, or publishing APIs do not reject the URL.
Use this workflow when the source system cannot send multipart files.
Multipart is still the upload format. The Base64 step is a local conversion step for source systems that expose the file only as a string.
AI image outputs
Decode generated image strings into image bytes, then create public image URLs for moderation, editing, or publishing.
Webhook payloads
Handle small encoded files from webhooks that do not support multipart transfer at the source.
Form and API bridges
Turn encoded attachments into a URL field that downstream systems can fetch.
Confirm the returned URL serves the decoded file bytes.
The handoff is only useful if the next API can fetch the decoded file from a direct URL with the expected content type.
Run curl -I
Check the returned URL and confirm `200 OK` with the expected `Content-Type`.
Keep cleanup metadata
Store `file_id`, `expires_at`, and `delete_url` near the job that consumed the URL.
Use multipart for larger files
If your source can send bytes directly, skip Base64 entirely and upload the file as multipart.
Validate the encoded file before blaming the destination API.
The URL can only be as useful as the decoded file. Bad padding, wrong MIME type, or missing filename metadata will surface later as fetch failures.
Wrong MIME type
If a PNG is labeled as text, image and social APIs may reject it.
Large payload
Base64 adds overhead. Use multipart upload for larger files or platform limits that reject large JSON bodies.
Data URI prefix
Strip or handle prefixes such as `data:image/png;base64,` according to the final API contract.
Copy the same upload shape into code
base64 --decode image.b64 > image.png
curl -X POST https://api.getfileurl.com/v1/files \
-H 'Authorization: Bearer $GETFILEURL_KEY' \
-F 'file=@image.png;type=image/png' \
-F 'visibility=public'Common questions
When should I use Base64 instead of multipart upload?
Use Base64 only as a source format when a tool gives you an encoded string. Decode it first, then use multipart upload when calling GetFileURL.
What fields are needed to convert Base64 to a URL?
You need the Base64 content, a filename, and a content type so your code can decode a real file and upload it as multipart form data.
Is Base64 good for large files?
Usually no. Base64 increases payload size and can hit JSON limits. Prefer multipart upload for larger files.