Wrapping every line of a plain list in quote characters is the small chore every developer knows, and it is governed by three different published rules depending on the target format. A colleague drops fifty IDs in a chat, and you need them as a JSON array, a SQL IN clause, or a quoted CSV row before any of them can be used. Adding quotes to a list is not really about the quote characters themselves; it is about which quote character to use, which delimiter to join on, and how the embedded quotes inside your data are escaped — and all three choices change depending on whether the target is JavaScript, a SQL console, or a spreadsheet import. The Add Quotes to Each Line tool does all three in one pass, applying the escaping each format actually requires: RFC 8259 for JSON (an embedded double quote becomes a backslash escape, and the array ends with no trailing comma), the ISO string-literal rule documented by PostgreSQL and SQLite for SQL (single quotes double, they do not take a backslash), and RFC 4180 for CSV (fields wrap in double quotes, embedded double quotes double, and the whole row sits on one line). Everything runs locally in the browser, input is capped at one million characters, and the list you paste in never leaves the page.
When wrapping every line in quotes is the actual task
The phrase "add words to a quote" usually refers to a writing convention: using square brackets [ ] to insert a clarifying word inside someone else's quotation, or using ellipses to mark omitted text. That is a grammar task, not a formatting task, and a quoting tool would not help. This article is about the developer task instead: turning a plain list of values into a syntactically valid snippet of code or data so the values can be consumed by a parser, a query engine, or an importer.
Common reasons the task shows up in real work: a teammate pastes a list of order IDs into a chat, and you need to query for them in WHERE id IN (...). A product manager sends feature names in plain text, and you need them as a JSON fixture for a unit test. An export from one spreadsheet needs to become a single quoted CSV row before a downstream import accepts it. An environment allowlist of email addresses is easier to maintain as a SQL literal than as a config file. An i18n string table or a feature-flag list in a config file needs every entry wrapped in matching quotes. In each case, the lines are the words you want to add to a quote — except the "quote" here means a JSON string literal, a SQL literal, or a CSV field, not a quotation mark around someone's prose.
The three escaping rules at a glance
The hard part of wrapping a list is not the wrapping itself; it is the escaping. Each common target format defines its own rule for what happens when the data itself contains a quote character, and the three rules are different from one another. The presets in the tool encode the published rule for each format so you do not have to memorise the difference.
| Preset | Wrap character | Escape rule for an embedded quote | Standard cited |
|---|---|---|---|
| JSON array | Double quote " " | Backslash escape: a " becomes \" | RFC 8259 |
| SQL IN clause | Single quote ' ' | Double the single quote: it's becomes it''s | ISO / PostgreSQL / SQLite |
| CSV row | Double quote " " | Double the double quote: say "hi" becomes "say ""hi""" | RFC 4180 |
| Backticks (template literals) | Backtick ` ` | Backslash escapes both the backtick and the ${ interpolation opener | JavaScript template literals |
The same input produces visibly different output under each preset because the escaping differs. A line that reads she said "hi" comes out of the JSON preset as "she said \"hi\"", out of the SQL preset untouched inside single quotes (the double quote is just data, not a delimiter), and out of the CSV preset as "she said ""hi""". None of these is interchangeable. Pick the preset that matches where the output will be pasted, and the escaping will already be correct.
How to wrap every line in quotes in three steps
For a list that is already clean — no blank lines, no leading or trailing whitespace, no rogue commas — the workflow is the same regardless of the target format. Each step is shown below.
- Paste your list, one item per line, into the input box.
- Click the preset that matches your target: JSON array, SQL IN clause, CSV row, or plain quotes (with a separate backtick option for JavaScript template literals).
- Fine-tune the quote style, delimiter or escaping if your target needs something the preset does not cover by default, then copy the paste-ready result.
A short worked example makes the three steps concrete. Start with this input, one item per line:
widget-Awidget-Bwidget-C
Clicking the JSON array preset produces:
[ "widget-A", "widget-B", "widget-C" ]
Notice that the last line is not followed by a stray comma, which is what makes the result paste-ready: a JSON array with a trailing comma is a syntax error under RFC 8259 in most parsers. The status line reports how many lines were processed, so the count can be confirmed against the input. The same three steps apply to the SQL and CSV presets — the only thing that changes is the published rule the preset encodes.
Fine-tuning quote style, delimiter and escaping
The presets cover the common cases, but every choice is also exposed as an individual control. Quote style can be set to single, double, backtick, or none (the last option leaves the lines unquoted and is useful when you only want commas between fields). The delimiter is configurable too, with a default that matches the chosen preset — commas for JSON and CSV, commas wrapped in parentheses for SQL IN — and a toggle that decides whether the last line gets a trailing delimiter. The toggle is off by default, because a trailing comma in JSON or a trailing element inside IN (...) is a syntax error in most contexts. Turning it on is the right call when the target is a system that explicitly wants the trailing delimiter (some CSV dialects, some hand-rolled SQL pipelines).
Escaping can be switched off entirely, which is useful when the data is already pre-escaped and you only want the wrapping. Blank-line skipping and per-line trimming are independent toggles: turn trimming on to drop incidental whitespace at the start and end of each line without touching the content; turn blank-line skipping on so the output has no empty entries between items. Together, these controls let the tool match whichever minor dialect your target requires without leaving the page.
Why running the tool again wraps everything twice
A behaviour worth knowing up front: pasting the tool's own output back into it wraps the result a second time. A line that started as widget-A becomes "widget-A" after one run, and "\"widget-A\"" after two. This is by design, not a bug — a quoting tool cannot tell whether existing quotes in the input are part of the content or are wrapping that should be preserved, so it does the only safe thing and wraps again. If a different preset, different escaping, or different controls are needed, start from the original plain list rather than re-running on the output. Treating the tool as a one-shot converter from plain lines to paste-ready code keeps the workflow predictable and avoids the double-wrapping trap.
Pair it with cleanup before you quote
Most lists that arrive in chat or in an email are not ready to be quoted straight away: they often have duplicates, stray spaces, blank lines between sections, or inconsistent ordering. The cleanest workflow is to normalise the list first and then quote it. The site's Remove Duplicate Lines tool collapses repeated entries while keeping the first occurrence, the Compare Two Lists tool can confirm what changed between two versions, and the quoting step then runs once on a clean, deduplicated input. Piping the result into a SQL query or a JSON fixture is far less error-prone than quoting first and cleaning afterwards, because the quoted commas and brackets make the cleanup tools harder to apply to the output.
Related reading: AutoCAD Line End Style: Convert Text Breaks to \n.
Related reading: Dedupe Text: A Practical Guide to Removing Duplicate Lines.