Markdown, JSON, XML and code files in ChatGPT

Why text formats are the reliable ones

Every other format needs unpacking before ChatGPT sees any words. A PDF has to be parsed. A DOCX has to be unzipped and its XML walked. That step is where things go wrong.

Text formats skip it. The file is the content.

Which is why the general test works: open a file in a text editor, and if you see readable words, ChatGPT can read it too. Markdown, JSON, XML, YAML, CSV, HTML and every source code file pass that test.

Markdown is the best of them

Worth singling out, because it solves a problem plain text has.

Plain .txt keeps your headings as text but loses the fact that they were headings. Everything flattens into one undifferentiated block, and on a long document that makes section-by-section work harder.

Markdown keeps the structure visible. A ## Section title is unambiguously a heading, lists stay lists, and tables stay tables. It costs nothing and it makes requests like this work properly:

Summarise this section by section, using the document's own headings.

JSON and XML

Both are read reliably, and there are two things worth doing.

Say what it is. "This is an API response describing orders" gets you a much better reading than the raw structure alone, because field names are rarely as self-explanatory as they look to the person who wrote them.

For very large files, send a sample plus the schema. A hundred thousand records is a lot of tokens and mostly repetition. Twenty representative records plus a description of the fields answers almost every question the full file would, and it fits.

The exception is when the question is genuinely about the whole dataset, such as counting or finding outliers. In that case a CSV upload is a better route, since spreadsheets are exempt from the token cap and are analysed as data.

Code files

The extension almost never matters, because source files are read as plain text. Python, Rust, SQL, Terraform, or something obscure all behave the same.

If a file is ever refused, rename a copy to .txt and it goes through.

For anything spanning several files, concatenate them with a header line naming each, so the structure survives and it costs one upload rather than several:

for f in src/**/*.py; do echo "=== $f ==="; cat "$f"; done > bundle.txt

The limits that apply

512 MB per file, and 2 million tokens for text files.

Because these formats are so compact, the size ceiling is effectively unreachable and the token cap is the only real constraint. A very large codebase or a big JSON export can reach it, and when it does the file is truncated with no warning.

The check is the same as always: ask what the last thing in the file is. If it cannot say, it did not get there.

Where these formats do not help

HTML with heavy markup. A saved web page can be mostly tags, and the tags consume length without carrying meaning. Copying the visible text is often better than uploading the file.

Minified anything. A minified bundle is technically text and practically unreadable, to you and to ChatGPT alike. Send the source.

Binary formats with text extensions. Rare, but some tools write binary into a .dat or .log. The text editor test settles it in seconds.