A language model, unless told otherwise, produces prose of variable length in whatever format it considers most appropriate for the question. That is fine when you want a conversational response. But when you need the results in a specific format — to process with code, feed into a database, display in a table, or integrate into a workflow — free format is a problem.

The good news is that modern models are very capable of producing outputs in precise formats. The bad news is that you have to ask for it explicitly and correctly.

The problem with free format

Imagine you ask the model to analyse ten products and compare them. In free format, you will probably receive several paragraphs of prose, some subheadings, perhaps a list at the end. The content may be good, but if you need the data to feed a spreadsheet or compare columns, free format does not work.

The model does not know your use case. It does not know whether what you produce will go to an email, a dashboard, a database or a presentation. Without format instructions, it chooses what feels most natural for the prompt’s context.

The solution: always specify the format when it matters.

Structured text formats

For most professional uses, these are the most useful formats:

Numbered and bulleted lists. Useful for sequential steps, option lists, key points. Ask: “Respond as a numbered list with exactly five points. Each point in a single sentence.”

Structured Markdown. For documents with hierarchy. Ask: “Use second-level headings (##) for each category and dash lists for examples under each one.”

Question-and-answer format. For FAQs or documentation. Ask: “For each question, write ‘Q:’ followed by the question and ‘A:’ followed by the answer in two or three sentences.”

Card format. For structured information about entities (products, people, companies). Ask explicitly for the fields you need:

For each company, use exactly this format:
Name: [name]
Sector: [sector]
Founded: [year]
HQ: [city, country]
Strengths: [2-3 sentences]
Weaknesses: [2-3 sentences]

JSON for system integration

When you need to connect the model’s output with code or external systems, JSON is the standard format. Modern models produce valid JSON consistently when asked correctly.

Asking for basic JSON:

Extract the data from this CV and return it in 
JSON format with exactly these fields:
{
  "name": "",
  "email": "",
  "phone": "",
  "experience": [
    {"company": "", "role": "", "years": ""}
  ],
  "education": [
    {"degree": "", "institution": "", "year": ""}
  ]
}
Do not include any additional text outside the JSON.

Important JSON instructions:

  • Ask for no additional text outside the JSON (prose added before or after breaks parsing)
  • Provide the exact schema, including types and field names
  • If values can be null or empty arrays, specify it
  • For optional fields, indicate whether they should be omitted or included as null

Models sometimes “wrap” JSON in Markdown code blocks (json ... ). If you are going to parse it programmatically, ask explicitly not to wrap it, or write code that extracts it from the block.

Tables and comparisons

Tables are especially useful for comparing options. The key is specifying the exact columns you need:

Compare these five project management tools in a 
Markdown table with these columns:
| Tool | Price/month | Max users | Key features | Best for |

Limit each cell to a maximum of 10 words.

A common mistake is asking for “a comparison table” without specifying the columns. The model will choose the comparison dimensions it considers relevant, which may not be the ones you need.

For numerical tables (financial data, statistics), always add: “Use only the data I provide. If a data point is not available, write ‘N/A’. Do not invent any numbers.”

Controlling length

Output length is a parameter many users ignore, but it has a large impact on the usefulness of responses.

Length instructions that work:

  • “Respond in no more than 150 words”
  • “Maximum three sentences per point”
  • “One paragraph of 4-6 lines”
  • “Executive response: a single sentence with the main recommendation”

Instructions that work less well:

  • “Be brief” (ambiguous)
  • “Don’t go on too long” (the model decides what is “too long”)
  • “Give me a long detailed response” (the model may interpret “long” very differently)

When you need outputs that feed systems — forms, templates, presentations — always combine the format instruction with a specific length instruction. That ensures what the model produces fits directly into the destination without needing manual editing.

The final key: test and adjust. The first version of format instructions is rarely perfect. When the output is not exactly what you need, adjust the format instruction — not the content — and try again. Once you have a set of instructions that consistently produces the correct format, save it as a template for reuse.