The awk one-liner awk '{ print "\"" $0 "\"" }' file wraps every line of a plain list in double quotes, and that single command is the reason "awk add quotes to each line" is such a common search the moment a colleague pastes fifty IDs into a chat. It is fast, it is terse, and for a clean ASCII list with no embedded punctuation it produces exactly the output a developer wants. The trouble starts the moment a value contains a double quote, a single quote, an apostrophe, a comma, or anything else the destination format treats as special. An awk one-liner has no concept of JSON string literals, SQL string constants, or RFC 4180 CSV fields, so it cannot escape the content the way each format actually requires. The result is a list that looks correct at a glance and breaks the parser on first use. A quoting tool that follows each format's published escaping rule produces output that pastes cleanly into a query console, a JSON document, or a spreadsheet import, with no manual cleanup pass and no second round of find-and-replace.
Why the awk pattern falls short for real lists
A typical awk pipeline stops at the prefix and suffix. It does not know whether your destination is a JSON array, a SQL WHERE id IN (...) clause, or a CSV row, and it has no built-in notion of how each of those formats treats a quote inside a value. That limitation shows up the first time the input contains anything but plain identifiers.
Consider three lines that look harmless in a chat message: O'Brien, say "hi", and line, with comma. An awk pipeline that only adds outer quotes produces "O'Brien", "say "hi"", and "line, with comma". None of those three lines is a valid string in any of the three target formats. The first breaks SQL because a single quote ends the literal early. The second breaks JSON because the inner double quote is not escaped. The third breaks CSV because an unquoted comma is treated as a field separator, so the field count is now wrong. The pattern is not subtle: the awk approach trades correctness for brevity, and correctness is exactly what the downstream parser will demand.
Add Quotes to Each Line in three steps
- Paste your list, one item per line, into the input field.
- Click the preset that matches your destination: JSON array, SQL IN clause, CSV row, or Plain quotes. The Backtick option covers JavaScript template literals and escapes the interpolation opener so pasted content cannot inject an expression.
- Copy the paste-ready output. If finer control is needed, open the per-line controls for quote style, delimiter, trailing delimiter on the last line, escaping on or off, blank-line skipping, and per-line trimming, then copy.
The whole flow takes a single click and the result reports how many lines were processed, so the count can be sanity-checked against the original list. Re-running the tool on its own output wraps it again by design, because a quoting tool cannot tell whether an existing quote is content or wrapping from a previous pass; to apply new settings, start from the original list.
What each preset actually does
The four presets are not four skins over the same wrapper. Each one implements a different published rule for how embedded characters are escaped, and that is the part a hand-rolled awk one-liner cannot replicate.
| Preset | Standard followed | Embedded quote becomes | Wrapping quotes and surrounding syntax |
|---|---|---|---|
| JSON array | RFC 8259 | \" (backslash-escape); backslash itself doubles | Double quotes; wrapped in [ ] |
| SQL IN clause | ISO SQL / PostgreSQL / SQLite | '' (two single quotes, no backslash) | Single quotes; wrapped in ( ) |
| CSV row | RFC 4180 | "" (two double quotes) | Double quotes; row emitted on one line |
| Backtick (template literal) | JavaScript template literal grammar | Embedded backtick and ${ are escaped | Backticks |
The SQL rule deserves attention because it surprises people coming from a JSON mindset. In JSON, escaping uses a backslash. In SQL, the standard rule used by PostgreSQL and SQLite is to double the single quote, not to backslash it, so the value it's becomes 'it''s' in a valid WHERE col IN (...) list. The CSV rule is the third distinct pattern: fields are wrapped in double quotes and an embedded double quote is replaced with two double quotes, which is why the resulting row is always emitted on a single line. These three rules are not stylistic choices — they are the rules parsers actually implement — and the difference is exactly what the presets encode. Each preset is pinned against the standard it cites: RFC 4180 for CSV and the PostgreSQL lexical structure documentation for SQL string constants.
The trailing-delimiter toggle, explained
By default the last line carries no trailing comma, because a JSON array or a SQL IN list with a trailing delimiter is a syntax error in most contexts. That is the right default for paste-ready output. When the target format does want a trailing delimiter — for example, when several quoted lists are concatenated into a larger structure — the toggle adds it. The control is explicit so the choice is visible and reversible rather than buried in a hidden assumption about the destination.
Everything the presets do is also available as individual controls: quote style including none, delimiter with or without a trailing one on the last line, escaping on or off, blank-line skipping, and per-line trimming. The same input can therefore be quoted four different ways under the JSON preset alone if the controls are adjusted.
What happens on re-run, and why
One behaviour is documented rather than hidden: running the tool on its own output wraps it again. A quoting tool cannot know whether an existing quote in the input is content or wrapping from a previous run, so the safe behaviour is to wrap again. If a different preset or different settings are needed, the path back is to start from the original list. The same trap catches shell pipelines that accumulate wrapping quotes through each stage of a pipeline, which is one more reason to keep the quoting step as a single, explicit operation.
When awk is still the right tool
Awk is not obsolete for this task. It is the right tool when the work happens inside a Unix pipeline, when the input is guaranteed clean ASCII, when the destination format is not yet known, or when the quoting is one step in a larger transformation that awk is already driving. The moment the destination format has published escaping rules — JSON, SQL, CSV, JavaScript template literals — and the input contains anything more interesting than identifiers and numbers, a quoting tool that follows the right standard is faster, less error-prone, and easier to audit. The escape rules are public, the presets are pinned against the standards that define them, and the resulting list can be pasted into a query console, an editor, or a spreadsheet import without a second find-and-replace pass. The browser-based Add Quotes to Each Line tool handles the most common destinations in a single click and keeps the data local: input is capped at one million characters and processed in a single linear pass, so even long lists return instantly, and nothing is uploaded or stored.
Related text utilities for lists
If the list you are about to quote came from a chat message or a spreadsheet export, it is worth running it through a duplicate-line remover and a list comparison tool first. Cleaning the list before quoting keeps the output a true set of unique values, which is usually what a JSON fixture, a SQL IN clause, or an environment allowlist is meant to represent. If the wrapping you actually need is arbitrary text rather than quotes — for example, surrounding every line with HTML tags or a constant prefix — a dedicated prefix and suffix tool is the better fit, because the rules that govern quotes are exactly what this page is built to encode.