How to Prompt for Tables and Structured Data

TL;DR: Name the exact columns instead of describing the table, give a literal value for "unknown" (N/A or NOT STATED) and permit its use, fix the row order and row count, and provide one worked example row. Do this for markdown tables, CSV, JSON records, and text you hand the model to extract from. Each fails differently, and a table with every cell filled is not proof any of them are correct.

Why Is a Table the Riskiest Format You Can Ask For?

Because it looks finished even when it isn't. Ask a model for a paragraph and a gap in its knowledge shows up as a hedge: a "sources vary," a sentence that trails into vagueness, a caveat you can spot on a skim. Ask the same model for a table comparing five things across four columns, and it fills all twenty cells with identical visual confidence, whether it actually knows the value, half-remembers it, or is producing something plausible-sounding because an empty cell reads to it as an incomplete answer. Nothing in the table's appearance distinguishes a verified figure from a guess. That is the single fact this whole page is built around: a filled cell is not evidence.

This isn't an argument against tables. A markdown table, a CSV file, a JSON array of records, and a comparison matrix are the right shape for exactly the jobs prose is wrong for: side-by-side comparison, machine parsing, spreadsheet import, and structured extraction. The fix is not avoiding tables; it's prompting them the way you'd write a form, with an explicit rule for what goes in a field you can't fill honestly. Every template on this page carries that rule. Skip it, and you get a table that looks complete and is quietly wrong in whichever cells the model had no real basis for.

The stakes are higher than they look because tables travel. A hedge-filled paragraph tends to stay a paragraph; a table gets copied into a spreadsheet, a slide, or a client deliverable, formatting intact, with nobody re-reading the individual cells for confidence the way they'd re-read a sentence. The container's tidiness is exactly what lets a wrong value ride along unchallenged.

A concrete version of this: ask a model for "a table of the top 10 project management tools in 2026, with pricing" and you will almost always get ten neat rows. Some of those prices will be current. Some will be from an older plan the vendor has since changed. One row might name a tool that has since been acquired or renamed. Nothing in the table signals which is which, because the model wasn't asked to signal it, and a table format has no built-in place to hedge the way a sentence does.

How Do You Prompt for a Markdown Table?

Name the columns, in order, instead of describing what you want compared. "Make a table comparing these three tools" leaves every decision (which columns, how many rows, what to do with a gap) up to the model. Naming the columns removes that decision entirely, and a worked example row removes the rest: a model copying a shown pattern drifts far less than one inferring a shape from a description. The difference is the gap between a request and a specification; a request describes what you want in general terms and leaves the model to design the container, while a specification hands over a container that's already built and asks only for values.

Present this as a markdown table.
Columns, in this exact order: [Column A] | [Column B] | [Column C]
Exactly [N] rows, one per [item], in this order: [item 1, item 2, item 3].
Units and format stated once here, not per cell: [e.g. Price in USD/month].
If a value isn't available, write "N/A" — do not estimate or guess.
No text before or after the table.

Here is one example row in the exact shape I want:
| [Example value A] | [Example value B] | [Example value C] |
Match this shape exactly for the remaining rows. Only change the values,
not the column count or the order.

Build a table from the list below.
Columns: Item | Category | Status
Sort by Status, then alphabetically within each Status.
Do not add a row for anything not in the list below.
[paste your list]

Rebuild the table above but add one column: [New Column].
Keep every existing column, row, and value exactly as they were.
Only add the new column; do not regenerate the rest.

If a source list runs long, say what to do about it rather than letting the model decide silently:

If there are more than [N] items, show only the first [N] and add one
line after the table: "Showing [N] of [total] items."
Do not silently truncate without saying so.

How Do You State Units and Formats So They Aren't Repeated Per Cell?

Put the unit, currency, or format once, in the column header, not inside every cell. "Price (USD, monthly)" as a header beats "$4.99/mo" written out fresh in each row, because a long table generated in one pass will sometimes drift formats partway through: a dollar sign in row two, a bare number in row nine, a "/month" suffix that appears twice. Stating the format once in the header spec removes the chance for that drift to start.

Columns: Price (USD, monthly) | Founded (year) | Team size (number of people)
Do not repeat the unit inside any cell — write "4.99", not "$4.99/mo".
State the unit once, in the column header, exactly as shown above.

This also gives you a retrofit move for a table that already drifted, rather than starting over:

Reformat the table above so every cell in a column uses the same unit
and the same number of decimal places. State which unit and format you
used for each column in the header, and convert any cell that doesn't
already match instead of leaving it inconsistent.

How Do You Get Clean CSV Output From AI?

CSV has one failure mode the others don't: a comma inside a value breaks the column count the moment it lands in a spreadsheet, and nothing about the model's output looks wrong until you try to import it. Say the delimiter explicitly, and say what happens to a value that contains it, rather than trusting the model to quote correctly by default.

Output this as CSV.
Delimiter: comma.
Header row exactly once, these column names: [col1,col2,col3]
Wrap any field containing a comma or line break in double quotes.
No explanatory text before, after, or between rows — CSV only.

Output this as CSV using semicolons as the delimiter instead of commas,
because the values contain commas (addresses, descriptions, or numbers
with thousand separators). Column order: [col1;col2;col3]

Convert the list below into CSV.
Columns: [col1,col2,col3]
Exactly one row per entry in the list — no more, no fewer.
If a field is missing from an entry, leave it as an empty pair of quotes (""),
not a guessed value.
[paste your list]

Locale is the other place CSV quietly breaks: a source that writes numbers with a comma as the decimal separator produces a file that looks fine until it's imported somewhere expecting a period, and nobody catches the mismatch by reading the CSV as text.

Output as CSV. Use a period for decimal separators and no thousand
separators inside any numeric field, regardless of how the source
formatted them, so the file imports cleanly into a standard spreadsheet.

How Do You Prompt for JSON Records Instead of a Table?

Reach for JSON only when something downstream will parse it: a script, an import job, another tool's input field. A table is read by a person who tolerates a slightly uneven row; JSON is read by code that breaks on a missing key or a string where it expected a number. Give the exact keys and one example object, then say to match the shape and change only the values.

For row-shaped data specifically, ask for an array of objects rather than an object whose values are parallel arrays. An array of objects keeps every record's fields together, so a missing or malformed entry stays contained to that one object instead of silently shifting every array's indexing out of alignment with the others.

Return this as a JSON array of objects, one object per [item].
Exact keys and types: { "name": string, "count": number, "notes": string }
If a field doesn't apply, use null — do not omit the key and do not invent a value.
No markdown code fence, no explanation text outside the JSON.

Here is one example object in the exact shape I need:
{ "id": "example-1", "label": "Example Label", "value": 42 }
Return an array of [N] objects matching this shape exactly, one per item
in the list below, in the same order as the list.
[paste your list]

Nested structures need the same worked-example treatment as flat ones: show one complete nested object, not just the top-level keys, or the model will guess the shape of whatever sits inside the nested field.

Return a JSON array where each object has a nested "details" object.
Example of one full object, including the nested part:
{ "id": "1", "details": { "start": "2026-01-01", "end": null } }
Match this nested shape exactly for every object in the array.

Convert the table above into a JSON array.
Use these keys, matching the table's columns in order: [key1, key2, key3]
Any cell that reads "N/A" in the table becomes null in the JSON, not the
string "N/A" and not an omitted key.

If the JSON needs to satisfy an actual schema (nested objects, enums, an API request body an application will validate), that's a deeper topic than table-shaped prompting, and the API-level features that guarantee schema compliance work differently from a plain chat window. JSON Prompts Explained covers the syntax and when strict JSON hurts more than it helps, and the free JSON prompt generator has ready-made schemas by job plus the exact request shape for each major API. One vendor detail worth knowing if you're calling an API directly rather than typing into a chat window: OpenAI's own documentation on its older JSON mode states that the request must include the word "JSON" somewhere in the prompt, and that the API will throw an error if it doesn't; that's a constraint with no equivalent inside the consumer ChatGPT app, where nothing enforces a schema at all (platform.openai.com/docs/guides/structured-outputs, accessed August 28, 2026). Treat API behavior and chat-app behavior as two different environments — a rule that holds for one doesn't automatically hold for the other.

How Do You Prompt for a List of Records With Fixed Fields?

Sometimes a table is the wrong shape for structured data even when JSON is overkill: a set of contact records, product specs, or profile summaries reads better as repeated labeled blocks than as a wide table with mostly-empty columns for the records that don't share every field. This shape is worth choosing specifically when your records don't all carry the same attributes, since a table forces every record into identical columns whether or not they apply, which is exactly the situation that produces the guessed-value problem this page keeps coming back to.

For each [item] below, give me a record in exactly this shape:
Name: [value]
Category: [value]
Key detail: [value]
Status: [value or "Unknown"]
Blank line between records. Same four fields, same order, every time.
If a field doesn't apply, write "Unknown"; don't skip the label.
[paste your list]

Here is one worked example record:
Name: Example Corp
Category: Software
Key detail: Founded 2020
Status: Active
Produce [N] more records in this exact shape from the source below,
only changing the values.

Going the other direction works the same way: point at the table and the target shape, not at a vague "reformat this."

Convert the table above into individual records, one per row, using
this label format:
[Column A label]: [value]
[Column B label]: [value]
Keep every value exactly as it appears in the table; do not reformat
numbers or dates in the process.

How Do You Build a Comparison Matrix Without Getting Fabricated Cells?

A comparison matrix is the highest-risk table shape, because you're usually asking the model to compare things from its own knowledge rather than from text you supplied, which means every cell is a recall task and recall fails silently. It's also the shape most likely to include something you didn't ask about, since "compare X" invites the model to reach for whatever else it associates with X. The fix is the same unknown-value rule as above, plus a row-count and dimension check before you trust the result.

Compare these [N] items in a table with exactly these columns:
[Item] | [Dimension 1] | [Dimension 2] | [Dimension 3]
If a dimension doesn't apply to an item, or you aren't confident in the
value, write "N/A" — do not estimate, and do not omit the row instead.
Exactly [N] rows, one per item, in the order I gave them: [item list].

Before answering, list any dimension in the table above where you are
not highly confident in every value across all rows. Then produce the
table, and flag those specific cells with an asterisk.

You can also run a confidence check as a second pass on a table you already have, rather than building it into the first prompt:

Audit the table above. For each cell, state whether you are highly
confident, moderately confident, or guessing. Do not change any values;
only add a confidence column.

When the dimensions genuinely don't line up across the things you're comparing (one option with no published price, another with no equivalent feature at all), forcing them into parallel columns is often the wrong call before it's a formatting problem; how to decide what output format you actually need covers that decision in more depth than a table-specific page should.

How Do You Extract a Table From Text You Supply Without the Model Adding Facts?

Extraction is different from every shape above because the source of truth already exists in your text. The model's only job is transcription into a shape, and the entire risk is that it "helpfully" fills a gap in your source from its own general knowledge instead of leaving that gap marked.

Using only the text below, fill in this table. Do not use any outside
knowledge, even if you're confident about a value the text doesn't state.
Columns: [Column A] | [Column B] | [Column C]
For anything the text doesn't explicitly state, write "NOT STATED" —
do not infer it from context.

TEXT:
[paste your source text]

Extract every [entity type] mentioned in the text below into a table
with columns: Name | [Attribute 1] | [Attribute 2]
One row per distinct mention. If the text mentions the same entity twice
with conflicting details, keep both mentions and flag the conflict in
a Notes column rather than picking one.

TEXT:
[paste your source text]

For a longer document, ask for a location reference alongside each row rather than trusting that one pass covered everything:

Using only the text below, extract a table with columns:
[Column A] | [Column B] | Source location
For "Source location," note which paragraph or section each value came
from. If a row's value isn't stated anywhere in the text, write "NOT
STATED" in that cell and "n/a" in Source location.

TEXT:
[paste your source text]

How Do You Stop AI From Inventing Extra Rows?

This is a distinct failure from a guessed cell value: instead of a wrong answer inside a row you asked for, the model adds a whole row you didn't. It shows up most often on "list all of X" requests, where a model rounds a genuinely finite list up to a tidier-looking count, and on comparisons, where it adds a plausible extra competitor you never named.

List exactly the items below in a table — do not add any item, category,
or example that isn't in this list, even if it seems like an obvious
addition: [item 1, item 2, item 3].
After the table, state the row count. It must equal [N].

Compare only the [N] options I named: [option list].
Do not introduce any other option, even for context or as an aside.
If you think a relevant option is missing, say so in one sentence after
the table, outside the table, not as an added row.

A cheap second check: have the model count your source before it answers, rather than relying on it having counted correctly while generating the table.

Before producing the table, count the items in the list below and state
the count. Then produce exactly that many rows, no more.
[paste your list]

How Do You Fix a Table That Already Came Back Wrong?

Point at the specific defect rather than asking for a full redo. "Fix the table" tends to regenerate the whole thing, which is a second chance for a new error to appear in a cell that was actually fine the first time. Naming the exact column, row, or value that's wrong keeps everything else untouched, and it also gives you a smaller thing to re-check afterward instead of re-auditing a table you'd already verified once.

The table above has a problem: [describe exactly, e.g. "the Price column
for row 3 is missing" or "rows 2 and 4 are in the wrong order"].
Fix only that specific issue. Keep every other cell, row, and column
exactly as it was. Do not regenerate the whole table.

You already answered this in prose above. Convert that exact answer
into a table with columns: [Column A] | [Column B] | [Column C]
Use only the facts already stated in your prose answer — do not add,
remove, or research anything new.

What Should You Check Before You Trust Any Table an AI Gave You?

Run three checks before you use the output, in this order: row count against your source or your stated number, every "N/A" or "NOT STATED" cell against whether that gap is real, and every confidently specific-looking value (an exact price, a precise date, a named statistic) against something outside the model. Those last cells are exactly the ones most likely to be a plausible-sounding fill rather than a checked fact. A table's formatting gives you none of this for free; it only makes the wrong values easier to spot once you've decided to look.

If a table keeps drifting despite a correctly specified prompt (columns reordering, a row silently dropped, prose creeping back in around it), that's usually a different problem than the ones on this page, and why does AI ignore my format instructions covers the actual causes and fixes. For a broader pass at pressure-testing a prompt before you rely on its output for anything real, red-team your own prompt before you trust the output has eight adversarial tests built for exactly this kind of silent failure.

All of the free plan's five daily prompt enhancements (per our FAQ) are enough to test any of the templates above before you commit to using them on a real document or dataset.