tsvkit.org
TSV Toolkit
Sample data Say hi →

TSV to Code Array

JavaScript · Python · PHP · pandas · objects, rows, or columns

Paste a table, get a code literal you can commit. This is for the small-data case where a file would be overkill: a lookup table in a config module, a fixture for a unit test, a seed array in a migration, a hard-coded list of countries. Strings are properly escaped, so a value containing a quote or a backslash won't break the syntax.

code
Drop a .tsv file here, or
ready

How to use

  1. Paste or drop the TSV. The header row supplies the keys, so it should be valid identifier-ish text — header tools will snake_case it if not.
  2. Pick a language and a shape. Objects for readability, rows for compactness, columns for plotting.
  3. Set the variable name to whatever fits the file you're pasting into.
  4. Copy and paste it in. Then run your formatter — the output is valid but not opinionated about line length.

Which shape

Array of objects is self-documenting: each record names its fields, so the code reads correctly without reference to a header. It's the right default and the wrong choice for anything large, since every key is repeated on every row.

Array of arrays keeps the header as the first row, which is compact and matches what spreadsheet APIs (Google Sheets, SheetJS) and chart libraries expect. One array per column gives you a dict of parallel arrays — the shape plotting libraries want (plt.plot(data['x'], data['y'])) and what a columnar store looks like.

The pandas snippet is a different thing: rather than a literal, it embeds the TSV as a triple-quoted string and reads it with pd.read_csv(..., sep="\t", dtype=str). That's usually the better way to get a table into Python — the data stays readable as a table in the source file, and dtype=str stops pandas from silently converting your ID column to a float.

About coercion

With coercion on, numeric strings become real numbers, true/false become language-native booleans (True/False in Python), and empty cells become null/None. That's what you want for anything you'll compute with.

The usual warning applies, and it's sharper in code than in data: "01234" becomes 1234, "1.10" becomes 1.1, and a 20-digit ID silently loses precision because JavaScript numbers and Python floats can't hold it. When the column is an identifier rather than a quantity, turn coercion off and get strings everywhere — then cast the columns you actually need as numbers in the code.

FAQ

Should I really hard-code data into source?

For a few dozen stable rows — country codes, tax bands, test fixtures — yes: it's simpler, it's version-controlled, and it can't fail to load. For anything that changes independently of the code, or anything long enough to bloat a diff, keep it as a data file and read it at runtime.

Can it emit TypeScript types too?

Not here — the schema generator produces a TypeScript interface from the same data, so generate the interface there and the literal here, and they'll line up.

Is the output formatted?

One record per line with no line-length wrapping. Run Prettier, Black, or php-cs-fixer over it and it'll match your project's style; the syntax is valid to begin with.

What about Go, Ruby, Java, SQL?

Not currently. For SQL, TSV → SQL generates INSERT statements with dialect support, which is the more useful form. For other languages, the JSON output from TSV → JSON is close enough to most syntaxes to adapt in a couple of edits.

Privacy

100% client-side. No upload. See the privacy policy.