JSON vs CSV vs YAML for LLM Prompts

Choose CSV for tabular data, JSON for nested or structured data, and YAML for configuration-like prompts that need comments and readability. The right format depends on how your data is shaped, how the model has been trained, and how error-tolerant you need the prompt to be.

Why the Format Matters for LLMs

Large language models are trained on vast amounts of text, including code and data serialization formats. They learn statistical patterns from JSON, CSV, and YAML, so the format you choose affects how reliably the model extracts, transforms, or generates data. Using a format the model has seen frequently in its training data reduces the chance of syntax errors and improves adherence to the structure you request.

Beyond training exposure, the format influences token efficiency. Tokens are the chunks of text the model processes, and every character counts toward context limits and cost. CSV is often the most token-efficient for simple tables, while JSON adds braces, quotes, and commas. YAML uses indentation and newlines, which can be more compact than JSON but less compact than CSV for wide tables.

Understanding the Three Formats

CSV (Comma-Separated Values) is a plain-text table where each line is a row and commas separate columns. It has no schema, no nested structures, and no data types beyond strings. It is the oldest and simplest format, dating back to early computing, and is universally supported by spreadsheets and databases.

JSON (JavaScript Object Notation) is a hierarchical format with objects, arrays, strings, numbers, booleans, and null. It is the lingua franca of web APIs and is heavily represented in LLM training data. JSON is strict about syntax: a missing comma or an unquoted key breaks the entire structure.

YAML (YAML Ain’t Markup Language) is a human-readable serialization format that uses indentation to denote structure. It supports comments, multiple document streams, and a rich type system. YAML is common in configuration files (e.g., Docker, Kubernetes, CI/CD pipelines) and is designed to be read by humans before machines.

How to Choose: A Decision Framework

Ask three questions about your prompt data:

• Is the data tabular? If every item has the same fields and the fields are simple scalars (numbers, short strings), CSV is usually the best choice. It is compact, easy to generate, and models handle it well for tasks like classification or extraction.
• Is the data nested or varied? If items have different fields, nested objects, or arrays, JSON is the natural fit. It preserves hierarchy without flattening, and models are highly fluent in JSON syntax.
• Do you need comments or human editing? If the prompt is a template that a person will maintain, YAML allows comments and is more forgiving to read. It also avoids heavy quoting for long text values.

For example, if you are asking the model to extract product information from a list, CSV works well when every product has the same attributes. If you need to represent a product with optional specs, variants, and pricing tiers, JSON is better. If you are building a prompt template with instructions and examples, YAML can make the structure clearer to a human reviewer.

Token Efficiency and Cost Considerations

Token count directly affects API cost and context window usage. CSV is generally the most token-efficient for homogeneous tabular data because it uses only delimiters and values, without structural markup. JSON adds overhead: each key is repeated for every object, and braces, quotes, and commas add up. YAML sits between the two, but its indentation and occasional quoting can make it less efficient than CSV for wide tables.

However, token efficiency is not the only factor. If the model misinterprets a CSV without headers, you may need to repeat the schema in the instruction, which costs tokens. JSON is self-describing, so the model can infer the schema from the keys. YAML also carries field names but with less punctuation.

A practical rule: for a list of 100 simple records, CSV is usually the cheapest. For a complex object with nested fields, JSON may be cheaper than trying to flatten it into CSV. Always test with your specific model and prompt to measure actual token usage.

Common Problems and How to Avoid Them

CSV pitfalls: Commas inside values break the structure unless quoted. Newlines inside quoted fields can confuse models. Missing headers force the model to guess field meanings. Always include a header row and quote fields that contain commas, quotes, or newlines.

JSON pitfalls: Trailing commas, unquoted keys, and single quotes are invalid but models sometimes generate them. If you ask the model to output JSON, specify that it should be valid and consider using a parser to validate. For prompts, ensure your JSON is minified to save tokens, but keep it readable enough for the model to follow.

YAML pitfalls: Indentation errors are common because tabs are not allowed and spaces must be consistent. YAML also has special handling for strings that look like numbers or booleans (e.g., yes, no, on, off). Quote such values or use explicit type tags. Models may not be as fluent in YAML as in JSON, so test carefully.

A common misconception is that YAML is always more readable than JSON. For simple data, YAML is cleaner, but for deeply nested structures, YAML’s indentation can become ambiguous. JSON’s explicit braces make nesting visually obvious, even if it is noisier.

Format Comparisons in Practice

Consider a prompt that asks the model to list three fruits with their colors and calories. In CSV:

fruit,color,calories
apple,red,95
banana,yellow,105
cherry,red,50

In JSON:

[{"fruit":"apple","color":"red","calories":95},{"fruit":"banana","color":"yellow","calories":105},{"fruit":"cherry","color":"red","calories":50}]

In YAML:

- fruit: apple
  color: red
  calories: 95
- fruit: banana
  color: yellow
  calories: 105
- fruit: cherry
  color: red
  calories: 50

For this simple table, CSV is the most compact. JSON is the most verbose but is unambiguous. YAML is readable but uses more lines than CSV. If the model is asked to output data, JSON is often the safest because it is machine-parseable and models are highly trained on it.

Safety and Reliability Considerations

When using any format in prompts, be aware of injection risks. If the data comes from user input, it could contain instructions that override your prompt. For example, a CSV cell containing “Ignore previous instructions” could be interpreted by the model as a command. Use delimiters that are unlikely to appear in the data, and consider instructing the model to treat the data as data, not instructions.

Also, be careful with YAML’s ability to include multiple documents and custom tags. Some YAML parsers have had security vulnerabilities, but for LLM prompts, the risk is more about the model misinterpreting a colon or dash as structural. Always validate the model’s output if you plan to parse it programmatically.

For sensitive data, avoid putting secrets in prompts, as they may be logged. Formats do not change this, but be aware that CSV and YAML are plain text and can be read by anyone with access to the prompt.

Alternatives and Advanced Patterns

Beyond the three formats, you can use other structured representations:

• XML with tags like <item> can be useful when the model needs to distinguish between data and instructions, as the tags are explicit.
• Markdown tables are human-readable and models understand them well, but they are less compact than CSV and harder to parse programmatically.
• Custom delimiters like pipe (|) or tab can be used when commas appear in the data, but they are less standard.
• JSON Lines (JSONL) is a hybrid where each line is a JSON object, useful for streaming or when you need both tabular and nested data.

For prompts that include examples (few-shot learning), the format should match the format you expect in the output. If you want the model to return JSON, show JSON examples. If you want CSV, show CSV. Consistency between input and output formats reduces errors.

Frequently Asked Questions

Which format is best for LLM output? JSON is generally the safest for output because it is machine-parseable and models are highly fluent in it. Specify that the output must be valid JSON and use a parser to verify. CSV is fine for simple tables, but beware of commas in values. YAML is less common for output and can be ambiguous.

Does the model care about formatting? Yes, models are sensitive to formatting. They have seen more JSON in training data than YAML, so they are more likely to produce valid JSON. However, they can handle CSV well, especially with clear headers. Always test with your specific model.

Can I mix formats in one prompt? Yes, you can, but it may confuse the model. If you use CSV for input and ask for JSON output, the model can handle it, but it is clearer to use the same format throughout or explicitly state the output format.

How do I handle large datasets in prompts? For large data, consider summarizing or sampling instead of including everything. Token limits are a real constraint. If you must include a large table, CSV is the most token-efficient. For very large datasets, use a retrieval-augmented approach rather than stuffing everything into the prompt.

What if my data has newlines or quotes? In CSV, quote fields containing newlines or quotes. In JSON, escape newlines as \n and quotes as \". In YAML, use block scalars (| or >) for multi-line strings. Always test that the model interprets the data correctly.

Is YAML ever the best choice? Yes, when the prompt is a configuration or a template that a human will read and edit. YAML’s comments and readability make it ideal for prompts that are maintained over time, such as system prompts with multiple sections. For one-off data extraction, JSON or CSV is usually better.

Related

• Google Wallet Features I Wish I Knew Sooner
• Patreon vs Ko-fi: Which Is Better for Creators?
• Reasons Need Firewall Boost Security?