Image to Base64 for API calls

The two payload shapes every vision API uses

Multimodal APIs accept images in one of two shapes, and mixing them up is the most common reason a Base64 image comes back broken. OpenAI (GPT-4o, GPT-4.1 and the other vision-capable models) wants a content part with type: "image_url" whose image_url.url is the full data URI — prefix and all:

{
  "model": "gpt-4o",
  "messages": [{
    "role": "user",
    "content": [
      { "type": "text", "text": "Describe this image" },
      { "type": "image_url",
        "image_url": { "url": "data:image/png;base64,iVBORw0KGgo..." } }
    ]
  }]
}

Google Cloud Vision is the opposite: the image.content field takes the raw Base64 payload only — a data: prefix there causes an encoding error:

{
  "requests": [{
    "image": { "content": "iVBORw0KGgo..." },
    "features": [{ "type": "TEXT_DETECTION" }]
  }]
}

This page reads your image once and fills the templates for you, with the correct MIME type detected from browser-provided file metadata — the output uses a data:image/… prefix. This does not validate the image bytes or guarantee API support.

Need the deep dive per provider? The OpenAI vision Base64 guide covers image_url vs input_image and the failure modes, and the Cloud Vision Base64 guide covers the images.annotate body and batching. Verify current service limits before sending.

Step by step

1. Add the image. Drag it in, pick it, or paste from the clipboard.
2. Copy the payload for your API. OpenAI and Cloud Vision templates are filled in automatically; check the required fields before using the data URI or raw Base64 with another API.
3. Send it. The payload is valid JSON with the image already escaped — check the complete copy, supported image format, and request limits before sending.

Mind the request size

Image size and request limits vary by API and model. Base64 adds about 33% to the file size. Check the receiving API’s current limits before sending.

Why in-browser conversion matters for API work

The converter reads and encodes the selected file locally. It does not upload the file for conversion. Advertising and usage events may still make network requests; see the Privacy policy. Copying the output into another service shares the file when you send it there.

Debugging payloads that come back the other way

Many APIs also return images as Base64 inside JSON. When one does, the Base64 to image decoder previews and saves it, and the data URI extractor pulls every embedded image out of a bulk JSON or CSS dump in one pass.

When the endpoint is a chat platform

Chat file APIs go the opposite way: Slack, Telegram and Discord all reject data URIs and raw Base64 for uploads. The Slack Base64 fix, the Telegram sendPhoto guide and the discord.js Base64 guide show the decode-then-upload pattern each platform expects.

Email APIs work the other way. See the SendGrid inline image guide for raw Base64 attachments with a content_id, the Postmark CID example, and the Brevo transactional attachment guide for the fields its public endpoint documents. For the client-side rendering question across Gmail, Outlook and the rest, the Base64 image in HTML email guide has the full client matrix. For Node.js image processing, Jimp getBase64 returns a complete data URI.