Which APIs are supported?

The OpenAI Chat Completions format (model + messages array with system/user/assistant roles) and the Anthropic Messages format (model + max_tokens + messages with user/assistant roles and an optional top-level system field).

Does it send my payload to the provider?

No. The inspector only parses and validates the JSON locally in your browser. It never makes a network request and never transmits or stores your payload.

How accurate is the token estimate?

It is a heuristic — roughly one token per four characters of message content — so treat it as an order-of-magnitude guide, not an exact count. Use a dedicated tokenizer for billing-grade numbers.

What does a warning versus an error mean?

An error means the request will almost certainly be rejected (missing required field, invalid role, out-of-range value). A warning flags something unusual but legal — for example a very high temperature or an empty message — that you may have set by mistake.

What is the LLM API Payload Inspector?

Paste a full OpenAI or Anthropic chat request body and this inspector validates it — checks required fields, model name, message roles and ordering, parameter ranges (temperature, top_p, max_tokens) and gives a rough token estimate, so you catch a 400 before you spend a call. It runs free in your browser on Gera Tools, with nothing uploaded.

LLM API Payload Inspector

Name: LLM API Payload Inspector
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Catch a bad LLM request before the API does

A single malformed field — a missing max_tokens on Anthropic, a stray system role in the OpenAI messages array, a temperature of 5 — turns into a 400 and a wasted round-trip. This inspector parses your full request body and validates it against the provider’s rules locally, so you fix the payload before you ever hit the network.

Common payload mistakes by provider

OpenAI Chat Completions:

Using "role": "system" as a messages array entry is valid for OpenAI but placing system content in the system top-level field (Anthropic style) causes a 400
temperature must be 0–2; values above 2 are rejected
top_p and temperature should not both be set; the API accepts both but the guidance is to only alter one

Anthropic Messages:

max_tokens is required — no default exists; omitting it is the single most common Anthropic 400
The system prompt goes in the top-level "system" field, not in the messages array as a system role
Messages must alternate user/assistant; two consecutive user turns are invalid

How it works

You paste the JSON body and pick the provider. The inspector first parses the JSON and surfaces any syntax error precisely. Then it runs format-specific checks: that model is present and a string; that messages is a non-empty array with valid roles in a sensible order; that Anthropic requests include a positive integer max_tokens and put the system prompt in the top-level system field rather than the messages array; and that sampling parameters (temperature, top_p, top_k, presence_penalty, frequency_penalty) sit inside their legal ranges. Finally it sums the character length of all message content for a rough token estimate.

Reading the results

Each finding is tagged pass, warn or fail:

Fail — the API will almost certainly reject this request; fix before sending
Warn — legal but unusual: an empty message, a very high temperature, both temperature and top_p set simultaneously
Pass — field present, valid type, within range

Clear all fails first, review warns, then check the token estimate against your model’s context window. If you are within 10% of the limit, verify with a real tokenizer before sending — the estimate is approximate. Because the entire inspector runs in your browser, payloads containing prompt text never leave your machine.

Using the inspector in a development workflow

The inspector is most useful during two phases: initial prompt engineering and debugging production 400 errors. During prompt engineering, paste payloads as you build them to catch structural mistakes before running up API calls. When debugging a 400, copy the exact request body your code sends (log it at the HTTP layer) and paste it here — the inspector will identify the specific field that fails the provider’s validation, which the raw 400 error message often does not specify clearly.