How to Convert a List to JSON Array Without Hand-Typing Brackets

I keep a column of values in front of me almost every day: country codes pasted out of a spreadsheet, a list of feature flags from a Slack thread, SKU ids someone dumped into a ticket. And the target almost always wants the same thing back: a JSON array. The work in between feels small until you actually do it by hand. You wrap each value in double quotes, drop a comma after each one except the last, and slip the whole thing inside square brackets. On a list of eight items that takes thirty seconds. On a list of two hundred, one missing comma on line 140 breaks the parse and you spend ten minutes hunting for it.

This post is about that exact conversion: taking a plain list where each item lives on its own line and turning it into a valid JSON array. The mechanics are simple to describe and easy to get wrong, so it pays to know what a tool is doing for you and where the sharp edges are.

What the conversion actually does

Strip away the framing and a list-to-array conversion is three steps applied to every line:

Quote it. Each line becomes a JSON string, so apple turns into "apple".
Comma-join them. Every element except the last gets a trailing comma so the array parses.
Bracket it. The whole sequence is wrapped in [ and ].

That is the entire job for a string array. The reason it is worth automating is step one. A real JSON string is not just the text with quotes glued on either side. If a line contains a double quote, a backslash, a tab, or non-Latin characters, those have to be escaped so the result is valid and round-trips back to the original text. Glue quotes on by hand and one stray " inside a value detonates the whole array. The List to JSON Array converter builds output through real JSON serialization, so escaping is handled correctly instead of by string concatenation.

A worked example, start to finish

Here is the smallest case that shows the shape. Say you paste three lines:

a
b
c

The tool quotes each line, joins them with commas, and wraps the result:

["a","b","c"]

Three lines in, one array out, order preserved. Now scale that up. Paste a real column of forty country codes and you get a forty-element array with zero commas to count and zero brackets to balance. The transformation is the same; only the length changes, and length is exactly where hand-typing fails.

If you want a readable diff for version control instead of one tight line, switch to pretty print at two or four spaces:

[
  "a",
  "b",
  "c"
]

Same array, friendlier to a code reviewer.

String arrays vs number arrays

This is the decision that trips people up most often, so it deserves its own section. By default, treat every element as a string and you get ["1","2","3"]. That is correct for ids, ZIP codes, version strings, and anything where a leading zero matters. But plenty of targets want real numbers. An API that expects {"ids": [1, 2, 3]} will reject ["1","2","3"] because those are strings, not integers.

Type inference handles this. With it on, a line that is exactly a number, true, false, or null becomes that JSON primitive: 42 becomes the number 42, not the string "42". Flip it off when you want everything kept as a string.

The important detail is that good inference is strict. It only converts clean values. A line like 0x10, a version string like 1.2.3, an id like 007-A, or a phone number with a leading plus and dashes all stay strings. That strictness is a feature, not a limitation. It means the tool will not silently mangle an id that merely starts with a digit, which is the failure mode that turns a quiet data conversion into a 2 a.m. incident. When you genuinely want numbers, turn inference on and check that the values printed without quotes. When you want strings, leave it off and trust that nothing gets reinterpreted.

Trim empties and drop duplicates in the same pass

Real lists are messy. The column someone hands you has trailing spaces, a blank line where they hit enter twice, and the same tag repeated three times because they pasted from two sources. You can clean that by opening a spreadsheet, or you can do it in the same pass that builds the array.

Trim removes leading and trailing whitespace from each line, so apple becomes "apple" and not " apple ".
Skip blank lines drops empty rows so you never end up with stray empty-string elements like "" sitting in your array.
Remove duplicates keeps the first occurrence of each line and drops every later repeat. Feed it a, b, a, c and it collapses to ["a","b","c"].

One thing worth knowing about ordering: dedupe runs on the text you see, before type inference, so it matches on the visible line rather than on the inferred value. And if you want the result alphabetized for a stable diff, add sort. A numeric-aware sort puts 10 after 2 instead of before it, which is the order a human actually expects.

Pasting the result into code and config

Once the array is clean, where it goes determines which options you wanted. A few patterns I reach for:

Config files and test fixtures. Leave type inference off so codes stay strings, copy, and drop the array straight into the file. No hand-typed brackets, no missing comma on line 40.
API request bodies. Turn type inference on so each id becomes a real JSON number, pretty print at two spaces, and paste it into the body. The endpoint accepts the numbers because they are numbers.
SQL seed scripts. A trimmed, deduped, sorted array of values is a clean starting point you can reshape into an IN (...) clause or a values list.

And the conversion runs both ways. If a colleague pastes a long single-line array into chat and asks what is in it, switch direction and fan it back out to one element per line. String elements print without their surrounding quotes so you can scan the values, and a malformed array gives you a readable parse error instead of a blank box. If you need to clean up the JSON itself first, the JSON formatter will pretty-print and validate it before you split it.

Why I stopped doing this by hand

The honest reason I reach for a converter is not speed on small lists. It is that I do not trust myself to escape a stray quote correctly at the end of a long day, and a broken array is the kind of bug that hides until a build fails. The first time I pasted a list of forty product names — a few of which contained apostrophes and one with an actual double quote in the title — and got back a valid array with everything escaped properly on the first try, I stopped treating this as a thing I type and started treating it as a thing I convert. Everything runs in the browser tab, so the list never leaves the page, and copy-to-clipboard means I am one click from pasting it where it needs to go.

The conversion itself is three steps — quote, comma, bracket — but the value is in getting all three right every single time, on a list of any length, without a single comma to count.

Made by Toolora · Updated 2026-06-13