Analyzing images with AI in n8n: GPT-4o, Claude and Gemini multimodal vision

Multimodal models have changed the nature of image-processing workflows: GPT-4o, Claude and Gemini no longer stop at text — they "see". From n8n, that means a photographed receipt, a product photo or a user-uploaded image can be sent to the model with an instruction in plain language — "extract the total amount and the date", "is this photo sharp and well framed?" — and come back as structured data the rest of the workflow can use. This guide covers the whole chain: fetching the image, preparing it, sending it to the model (native node or HTTP Request), structuring the output, and avoiding the classic cost and reliability traps.

Getting the image in: webhook, email or Drive

Everything starts with the image entering the workflow as binary data — the mechanism n8n uses to carry files from node to node, alongside the JSON. Three sources come up constantly:

• Webhook: a form or mobile app sends the image as multipart/form-data. The Webhook node then exposes the file in the item's binary data, ready to be passed along.
• Email: the Gmail Trigger or Email Trigger (IMAP) node, with attachment download enabled, picks up photos sent by email — the favorite channel of field teams photographing receipts and delivery notes.
• Google Drive / storage: the Google Drive node (Download operation) or an HTTP Request node pointed at a file URL brings the image into the workflow when needed.

In all three cases, check the Binary tab of the node's output to confirm the file is there with the correct MIME type (image/jpeg, image/png…). That's what downstream nodes will consume — our guide on binary data in n8n covers how this works and its memory limits.

Base64 or raw binary: preparing the image for the model

Vision APIs generally accept images in two forms: a public URL the provider fetches itself, or the content encoded as base64 directly inside the request. The public URL is simplest when the image already lives online; base64 is unavoidable when the image exists only inside your workflow (email attachment, webhook upload).

To convert an n8n binary to base64, the most direct route is the Extract from File node with its "Move File to Base64 String" operation, which puts the encoded string into a JSON field. A Code node using Buffer does the same if you need more control. Keep in mind that a base64-encoded image weighs roughly a third more than the original file, and that it travels inside the execution's JSON — one more reason to resize first, which we'll come back to.

OpenAI node vs HTTP Request: two paths to vision

The simple path: the OpenAI node. The OpenAI node ships an Analyze Image operation under its Image resource: you give it the image (workflow binary, base64 or URL) and a text prompt, and it returns the model's answer. No message structure to build, no manual encoding — the option to pick when starting out, and the one we recommend in our guide to getting started with n8n's AI nodes.

The flexible path: the HTTP Request node. For Claude, Gemini, or to control OpenAI's parameters finely, an HTTP Request node pointed at the provider's API remains the royal road. The principle is the same everywhere: the message sent to the model is no longer a plain text string but an array of content blocks mixing a text block (your instruction) and one or more image blocks (the base64 along with its MIME type, or a URL depending on the provider). Each API has its own exact syntax for that image block — go by the provider's documentation rather than guessing field names. Credentials and authentication headers are set up exactly as for text: our article on connecting Claude and GPT to n8n covers that part.

One rule that applies to both paths: put as much care into the prompt as you would for text. "Describe this image" yields a vague paragraph; "List this receipt's line items with unit prices, then the total including tax; if a field is unreadable, return null" yields data you can actually use.

Concrete use cases

Reading receipts and expense slips. The flagship use case for expense reports: the receipt photo arrives by email or form, the model extracts merchant, date, total and tax, and the workflow feeds the accounting tool directly. It's the natural extension of AI-based data extraction from PDF invoices, applied to photographed documents rather than digitally generated ones.

Quality control on product photos. Before publishing to an online store, the model checks criteria defined in the prompt: neutral background, entire product visible, sufficient sharpness, no stray text. Non-compliant photos go to a correction queue with the rejection reason attached.

Moderating uploaded images. For any platform that accepts user images (avatars, listings, reviews with photos), a vision call between upload and publication filters out inappropriate content — as a complement to, not a replacement for, human moderation on edge cases.

Automatic alt-text. Generating image descriptions for accessibility and SEO: the model produces a concise, factual alt-text for every image in a CMS or media library — tedious by hand, near-free as a nightly batch.

General text extraction. Screenshots, badges, labels, signs: in many cases the multimodal model replaces classic OCR, with the advantage of structuring the result directly. Microsoft's technical report by Yang et al., "The Dawn of LMMs: Preliminary Explorations with GPT-4V(ision)" (2023 — see on Google Scholar), systematically explored these text-reading capabilities in images from the very first generation of vision models — while also documenting very real failure cases, notably on fine detail, which justify the safeguards in the next section.

Structuring the output as JSON

A descriptive paragraph is useless to a workflow: you need JSON. Two levers combine. First, the prompt: describe the expected schema explicitly (field names, types, null allowed when unreadable) and demand "JSON only, no surrounding text". Second, validation: a Structured Output Parser node (inside a LangChain chain) or a downstream Code node checks that the output matches the schema before propagating it. Our Structured Output Parser guide walks through this mechanism — all the more important with vision, since the model can return plausible but wrong values on fields it misreads.

A robust pattern for financial documents: ask the model for a confidence field per extracted value ("sure", "uncertain", "unreadable") and route uncertain items to human review rather than straight into the accounting entry. It's the same triage logic as for AI-based classification of incoming documents.

Cost and resolution: resize before sending

Images are paid for in tokens, and the bill depends on resolution: a smartphone photo sent at full definition costs noticeably more than a downsized version, often for an identical result. Two reflexes:

• An Edit Image node (Resize operation) before the call, bringing the image down to a width around 1000 to 1500 pixels — enough to read a receipt or describe a scene.
• When the provider offers a detail-level parameter (like OpenAI's low-resolution mode), use the economical mode for coarse tasks (moderation, general description) and save the detailed mode for reading fine print.

On a workflow handling hundreds of images a day, the gap adds up fast: instrument your calls as described in our article on tracking AI call costs in n8n to see the real effect of resizing on the bill.

Common pitfalls

• Blindly trusting the reading of small print. VAT numbers, amounts in tiny fonts, legal notices: this is exactly where models hallucinate plausible values. Cross-check critical fields (the total must equal the sum of the line items) and plan human review for high-stakes documents.
• Sending full-resolution images by default. Multiplied cost and added latency with no accuracy gain for most tasks — resizing beforehand should be the reflex, not the exception.
• Forgetting the MIME type in the image block. With HTTP Request, most APIs require the exact type (image/jpeg, image/png) alongside the base64; a wrong or missing type produces a 400 error that isn't always explicit.
• Writing the prompt as if it were text-only. Without a format instruction or a rule for unreadable fields, the model embellishes. Explicit schema, null allowed, "JSON only": three lines of prompt that change everything.
• Consuming the model's output without validation. A malformed JSON or a missing field must not crash the workflow or corrupt the downstream database: parse, validate, route the failures.
• Ignoring the size of binaries in the execution. Dozens of high-resolution images accumulated in a single execution weigh heavily on memory; process in batches and purge binaries once they're no longer needed.

Going further

Image analysis rarely stands alone: it usually feeds a broader document pipeline, where the same extracted data must be classified, stored and made queryable. That's exactly the territory of the RAG Assistant Pack (€119), which goes beyond analyzing isolated images to build an assistant able to query an entire document corpus — invoices, contracts and digitized receipts included. And if your entry point is a PDF rather than a photo, the guide on AI-based data extraction from PDF invoices is the direct companion to this article.