AI Prompting: how to ask an AI and get a useful answer
How to make an AI return the exact format you asked for
Getting tables, JSON, word counts and consistent structure out of an AI: the instructions that work, the ones that quietly fail, and how to check the output automatically.
The short answer
- To get an exact format, name every part of it, show one filled example, and then check the result in code rather than assuming it came back right.
- Describing a format is weaker than demonstrating it, because the model produces output by continuing patterns, not by filling in a template.
- Exact word and character counts are the one instruction that reliably misses, since the model works in tokens and cannot count what it has not written yet.
- Anything you leave unspecified gets filled with whatever was most common in the training data, which is why the same prompt drifts between runs.
- Valid structure is not correct content: a perfectly formed JSON object can contain a completely invented value, so check the numbers as well as the shape.
Three things get an exact format out of an AI, in this order: name every part of the format including what to do when a value is missing, show one filled example of the finished thing, and validate the result in code instead of trusting it. Most format problems come from the first step. People describe the output they want in a sentence, the model fills every gap they left with whatever was most common in its training data, and the answer arrives with extra commentary, renamed fields and a helpful summary row nobody asked for.
Why format instructions slip
A model is not filling in a template. It is producing one token after another, each chosen to be a likely continuation of everything before it. Format compliance is therefore imitation, not enforcement. If your instruction resembles a pattern it has seen a great deal of, it follows easily. If your format is unusual, the pull of the common pattern keeps leaking back in, which is why a request for plain prose so often comes back with bullet points and bold headers: that is what most instructional text on the internet looks like.
Two consequences follow. Positive instructions beat negative ones, because "do not use bullet points" still puts bullet points in the context while "write three continuous paragraphs" gives the model something to imitate. And vagueness is expensive. "Format this nicely" and "keep it short" contain no decision the model can check itself against, so it invents one, and it may invent a different one tomorrow. The general five part brief in how to write a prompt that gets a usable answer covers the rest of the structure. This article is only about the format line.
The four instructions that actually work
A field list with types and a rule for missing data. Not "return the invoice details as JSON" but: return one object per invoice with the keys invoice_number (string), amount_usd (number, no currency symbol or thousands separator), due_date (ISO format, YYYY-MM-DD) and status (one of paid, unpaid or disputed). Use null for anything not stated in the source. Add no other keys. That last sentence prevents the most common surprise, which is a helpfully added notes field that breaks your parser.
One filled example. A single worked instance of the output does more than three paragraphs describing it, and it settles a dozen questions you did not think to ask: capitalization, date style, whether an empty list is [] or omitted, how long each field runs. This is the strongest tool you have for anything idiosyncratic, and it is the whole subject of giving the AI examples that work.
A delimiter you can cut on. Ask for the answer wrapped in tags of your choosing, for instance between <output> and </output>, then extract only what sits between them. This does not stop the model writing "Here is the JSON you requested" first, but it makes that preamble harmless, which is a better deal than fighting it.
An instruction for the edge cases. Say what to do when there are zero results, when the source is ambiguous, when a value appears twice. Left unsaid, the model resolves these by producing something plausible, which is the exact behavior that turns a formatting problem into a fabricated value sitting inside a perfectly valid structure.
| What you want | The instruction that gets it | What happens without it |
|---|---|---|
| Machine readable data | Every key named, typed, and given a value for missing data | Key names and nesting change between runs |
| Exactly five items | Ask for numbered items, then count them in code | You get four or six and nobody notices |
| A specific length | A range plus a structural cue: three short paragraphs, 80 to 120 words | Exact word counts miss, often badly |
| Output with no chatter | Wrap it in a delimiter and take only the inside | A friendly preamble breaks your parser |
| A consistent table | Fixed columns in a fixed order, one row per input item, no totals | An extra column or a summary row appears |
| A matching style | Paste one example of the finished article | Generic corporate house style |
Why word counts and character counts fail
Ask for exactly 100 words and you will usually get somewhere between 80 and 130. This is not carelessness, it is structural. The model does not read or write letters and words; it works in tokens, chunks that average around three quarters of a word in English but split unevenly, so a single word may be one token or four. It has no reliable count of words available to it as it writes.
The deeper problem is that it cannot revise. Text is produced left to right, so by the time a sentence is half finished, the earlier choices are fixed. Hitting an exact total would require planning the length before the first word and tracking it throughout. Counting letters in a word fails for the same reason, which is why asking for a headline of exactly 58 characters is a waste of a prompt.
What works instead is structure the model can see in what it has already written. Five numbered bullets is far more reliable than 100 words, because the numbers are right there in the output. A range gives it room to land. A hard cap plus a countable unit ("no more than two sentences per bullet") is better still. And when the limit is genuinely strict, such as a field with a real character limit, generate slightly long and trim in a second step or in code rather than trying to hit the number in one pass.
Lists, tables and long outputs
For tables, state the columns, their order, and the rule for rows: one row per input record, no totals row, no merged cells, and a dash where a value is unknown. Without that, the model adds a summary row because tables in its training data usually have one. If you plan to parse the table rather than read it, do not ask for comma separated output, because a comma inside a field silently destroys the alignment. Tab separated or JSON survives contact with real data much better.
Long lists have a distinct failure. Ask for one line about each of 60 items and quality tends to hold for the first stretch, then the model starts compressing, merging similar entries, or quietly stopping early with a line about the remaining items following the same pattern. The fix is not a sterner instruction. Split the input into batches of a size that comes back complete, run them separately, and join the results, which is the basic move described in splitting a big task into linked steps.
It also helps to separate thinking from formatting. A prompt that asks the model to analyze something difficult and simultaneously emit strict JSON tends to do one of the two well. Ask for the analysis first, then send that answer back with a pure formatting instruction. The second call is nearly free in effort and much more obedient.
Check the output before you trust it
If a format matters enough to specify, it matters enough to verify. Parsing is the minimum: attempt to read the JSON or split the rows, and treat a failure as a failure rather than eyeballing it. The more useful checks are the ones on content, because syntax passing tells you nothing about truth. Count the output rows against the input rows. Confirm every value in a fixed field is one of the permitted options. Check that dates fall in the range you supplied and that amounts sum to a total you already know.
When a check fails, the efficient repair is to send back the specific error and only the failing item rather than restarting the whole job. Two settings help as well. Lowering the randomness setting makes structure more consistent, at some cost to variety in the wording; temperature and the other settings covers what that trades away. And several interfaces offer a structured output or JSON mode, which restricts what the model is allowed to emit so invalid syntax becomes impossible. That guarantees the shape, and only the shape. A schema cannot tell you the invoice number inside it was real.
The setup worth doing today
Take the prompt you run most often and give it twenty minutes. Replace the format sentence with an explicit field list, including the rule for missing values. Paste in one filled example of a correct result. Wrap the output in a delimiter so stray commentary stops mattering. Swap any exact word count for a range and a countable structure. Then write the three or four validation checks that would have caught the last thing that went wrong, and run the prompt five times to see how much it still varies. Once it is stable, it belongs in a prompt library you will actually reuse rather than in your chat history. If the answers are still arriving in the wrong shape after that, the cause is usually one of the prompt mistakes that ruin an answer rather than the format line itself.
Common questions
Why does the AI add extra text before the JSON?
Because helpful framing surrounds almost every code block it was trained on, so a bare structure is the unusual pattern. Telling it to return only JSON works sometimes. Wrapping the output in a delimiter you extract on works every time, because the preamble can appear and still be discarded. Where the interface offers a strict structured output mode, that removes the problem entirely.
How do I get an AI to write exactly 500 words?
You mostly cannot, and chasing it wastes prompts. Ask for a range such as 450 to 550, or specify a structure that produces roughly that length, like five sections of about 100 words each. If the number is genuinely fixed, get a draft slightly over and trim it in a second pass where you can tell the model the exact count it currently has.
Is it better to ask for JSON, a table or CSV?
JSON if a program will read it, because quoting rules protect values that contain commas, quotes or line breaks. A table if a person will read it. Avoid comma separated output for anything containing free text, since one comma inside a field shifts every column after it and the damage is easy to miss.
The format works in one chat and breaks in the next. Why?
Usually because parts of the format were never specified and are being resolved differently each time, or because a long conversation has pushed the original instruction far behind more recent text. Restating the format in the message that needs it, rather than relying on something you said twenty turns ago, fixes most of these cases.
Does asking more politely or more forcefully improve format compliance?
No. Capital letters and stern warnings add very little. What moves compliance is specificity and demonstration: a complete field list, one filled example, and an output wrapper you can cut on. If a format keeps failing after that, split the job so one call thinks and a second call only formats.