To add quotes to every line in Notepad++, the cleanest method is to copy the list from your file, paste it into the Add Quotes to Each Line tool, click the preset that matches where the output will land, and paste the finished string back into the editor — a round trip that takes a few seconds and produces correctly escaped JSON arrays, SQL IN clauses, or CSV rows without writing any regex inside Notepad++ at all. Notepad++ has a handful of ways to do this inside the editor — Find and Replace with a regular expression, the multi-caret Column Mode editor, the Macro menu, or a Python or Lua script run through the Plugins menu — and each of those routes will eventually produce a quoted list, but every one carries a sharp edge. A regex like Find what: ^(.+)$ with Replace with: "$1" needs the search mode switched to Regular expression, deals oddly with the last line of the file depending on whether it ends with a newline, and applies no escaping at all, so the moment any line contains an embedded double quote the output is no longer valid JSON, and the moment any line contains an apostrophe the output is no longer valid SQL, even though both look correct on screen. Column Mode editing inserts one character at a time across every selected line in a single keystroke, which is genuinely useful for repeated characters but cannot easily insert different characters at the start and end of each line without a second pass, and it also offers no escaping. A paste-back workflow sidesteps those problems entirely because the escaping rules for JSON, SQL, and CSV are different from one another, and a format-aware quoting tool encodes the rule that the destination format actually requires rather than the rule you remember. That distinction is the reason hand-rolled quoting almost always breaks the moment the data contains a quote, an apostrophe, or a backslash.
Why Notepad++ Manual Quoting Has Limits
The two Notepad++ approaches that come up most often are Find and Replace with Regular expression mode turned on, and Column Mode editing. Both are general-purpose tools that work for many tasks; neither was designed for quoting specifically, and both leak through the escaping problem.
The standard regex recipe is to put ^(.+)$ in the Find what field and "$1" in the Replace with field, with Search Mode set to Regular expression and Wrap around enabled. The output looks correct for a list of plain alphanumeric IDs or names — every line is wrapped in double quotes, and the list is paste-ready for many targets. Three real failures show up the moment the data contains special characters:
- An embedded double quote breaks the JSON preset the moment it appears, because nothing is escaped and the resulting string contains an unescaped quote inside a quoted string.
- An embedded apostrophe breaks the SQL preset for the same reason, because the single quote is also the string terminator in SQL and is treated as content only when doubled.
- The very last line may or may not receive a closing quote, depending on whether the file ends with a newline character, and Notepad++ does not flag the difference.
Column Mode editing handles the last-line problem better, because every selected line gets the same character at the same position. But it inserts one character at a time, so wrapping a line with both a leading and a trailing quote is two operations and a navigation step between them, and the same escaping limitations apply. A Python Script or Lua Script plugin can do the job cleanly, but only after the plugin is installed, the script is written, and the menu path is remembered for next time — too much ceremony for a one-shot quoting task.
The Paste-Back Workflow in Three Steps
The fastest route for one-shot quoting is to copy the list out of Notepad++, paste it into the browser tool, click a preset, and paste the result back. The whole round trip takes a few seconds and produces output that already matches the escaping rule for the destination format.
- Open the Add Quotes to Each Line tool in a browser tab. Switch to Notepad++, select the list of values, and copy it with Ctrl + C. Switch back to the browser, click into the input area, and paste with Ctrl + V. One item per line is all the tool needs.
- Click the preset that matches where the output will land. Four presets are available: JSON array wraps the list in square brackets and joins elements with commas; SQL IN clause wraps the list in parentheses and joins elements with commas; CSV row wraps each value in double quotes and joins them with commas on a single line; plain quotes wraps each line with the chosen quote character and joins with commas but adds no surrounding bracket.
- Fine-tune the result if needed, then copy and paste it back into Notepad++. Every preset exposes the same optional controls: quote character, trailing delimiter toggle (off by default so a JSON array does not end with a stray comma), escaping on or off, blank-line skipping, and per-line trimming. The status line under the output reports how many lines were processed. Copy the result with Ctrl + C, return to Notepad++, and paste with Ctrl + V.
What Each Preset Wraps Around the Lines
The four presets differ in three places: the quote character, the rule applied to embedded quote characters, and the surrounding punctuation. The table captures all three at once.
| Preset | Quote character | Embedded-quote rule | Surrounding bracket | Reference |
|---|---|---|---|---|
| JSON array | " | Backslash-escape: " becomes \" | [ ... ] | RFC 8259 |
| SQL IN clause | ' | Double the single quote: ' becomes '' | ( ... ) | PostgreSQL docs |
| CSV row | " | Double the double quote: " becomes "" | none | RFC 4180 |
| Plain quotes | User-chosen | Toggleable | none | — |
The point of the table is that every preset wraps the same input differently, and the difference lives in the three columns on the right. Paste JSON output into a SQL console and the backslashes show up as literal characters. Paste SQL output into a JSON parser and the doubled apostrophe is read as part of the string rather than as an escape. Paste CSV output into a JSON parser and the doubled double quote is read as two consecutive quotes rather than as an escape sequence. The right preset for the target format is the only way to get output that is valid syntax rather than output that just looks right.
When the Escaping Rules Are Different From What You Remember
The escape rule is the most common point of failure, because most developers carry one rule in their head and assume it applies everywhere. Three concrete cases illustrate the difference.
A line containing O'Brien looks fine inside double quotes: "O'Brien". Drop it into a SQL string literal without doubling the apostrophe and the parser reads the line as O (a terminated string) followed by an unterminated identifier, which is a syntax error rather than a successful query. The SQL preset in the quoting tool handles this by doubling the apostrophe to produce 'O''Brien', which is the form documented in the PostgreSQL lexical structure reference and used identically by SQLite and the ISO SQL standard.
A line containing she said "hi" looks fine inside single quotes: 'she said "hi"'. Drop it into a JSON string literal and the parser reads the line up to the first double quote and stops with a syntax error. The JSON preset handles this by backslash-escaping the embedded quote to produce "she said \"hi\"", which is what RFC 8259 requires.
A line containing a backslash is also handled differently per preset. JSON doubles it, so a single backslash becomes \\. CSV does not interpret backslashes at all, so a single backslash stays a single backslash. Standard SQL does not interpret backslashes in string literals either, so a single backslash stays a single backslash. A regex written in Notepad++ does not know which of these rules the destination format expects; a quoting tool whose presets are pinned against the relevant standard does.
Fine-Tuning for Messy Lists
Each preset also exposes its controls individually, which matters when the data does not fit the default behaviour exactly.
A common case is a list that includes blank lines — empty rows from the source spreadsheet, or separators a colleague pasted in for readability. The blank-line skip toggle drops those before wrapping, so the output array or IN clause does not contain an empty string entry that breaks downstream code.
A second case is whitespace inside each line. If the original list came from a copy-and-paste out of a chat window, every line may have a trailing space or a leading tab. The per-line trim toggle strips that whitespace before quoting, so " item1 " becomes "item1" rather than " item1 " with the spaces inside the wrapped string.
A third case is the trailing delimiter. JSON arrays and SQL IN clauses do not allow a trailing comma in most contexts, so the toggle is off by default and the last line is emitted clean. Some targets — a list passed to a shell command, a CSV variant that allows trailing delimiters, a config file that expects one entry per line with a semicolon at the end of every line — do want the trailing delimiter, and the toggle turns it on.
The result line reports how many lines were processed, which is a useful sanity check on very long lists.
Common Pitfalls When Quoting a Long List
The most common pitfall is quoting a list before cleaning it. If the same item appears twice, the quoting tool wraps it twice and the output JSON array or SQL IN clause contains a duplicate, which silently changes query results in SQL and silently bloats the data in JSON. Running the list through a duplicate-line remover first keeps the list unique before quoting, and the two tools together form a clean two-step workflow that matches what most developers already do by hand.
A second pitfall is re-running the tool on its own output. The tool cannot tell whether a quote character in the input is content or previous wrapping, so a second pass wraps the already-wrapped lines again, producing output like ""item1"", ""item2"" rather than "item1", "item2". If the quoting preset needs to change, start from the original unquoted list rather than from the previous output.
A third pitfall is hitting the input limit. The tool accepts up to one million characters in a single linear pass, which is enough for roughly 100,000 short IDs or names per paste; anything larger needs to be split first. Lists that big are rare, but they do happen when copying entire SQL result sets out of a query console.
A fourth pitfall is using the tool on a list whose values themselves contain line breaks. The tool processes one input line at a time, so a value that contains a newline will be split, and the embedded break will end up wrapped in quotes separately. For data that contains embedded line breaks — multiline descriptions, JSON values, log entries — clean those first or split the list by record before quoting.
Browser-Side Processing for Sensitive Lists
For many lists the source is sensitive: customer IDs, employee names, internal allowlists, environment configuration values. The Add Quotes to Each Line tool runs entirely in the browser; the input is never uploaded, never stored, and never attached to an account, so the data stays on the local machine throughout the round trip. The clipboard is the only boundary the data crosses, and that is the same boundary Notepad++ already uses when copying and pasting between documents.
This makes the tool usable for production data, test fixtures, and anything that needs to land in a real query or config file rather than a throwaway example. Processing happens in a single linear pass, so even lists of tens of thousands of items return the result without a perceptible delay.