A single quote
The shell form is the one to read: a backslash does not escape a quote inside single quotes
O'Brien
String Escape Converter
Escape one string for JSON, shell, SQL, regex and CSV at once. The shell form is the one to read twice: the obvious way to escape a quote does not work, and getting it wrong is command injection rather than bad formatting.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Escape. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A control character
Invisible, and it truncates the value in any C-based consumer
a b
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Escaping a shell single quote with a backslash
Inside single quotes the shell protects everything including backslashes, so there is no escape sequence for a quote. The naive form produces a command that runs something other than intended, which is command injection.
Instead:End the quoted run, emit an escaped quote, start a new one. Better, pass an argument array and use no shell at all.
Treating quote doubling as SQL injection defence
It is correct string syntax and not a defence. It depends on the connection character set, the server mode, and being right everywhere rather than almost everywhere.
Instead:Use a parameterised query. The value then never becomes part of the statement.
Splitting CSV on newlines before parsing quotes
A quoted field may contain a literal line break, which is legal. Line-first parsers cut the record in half.
Instead:Use a real CSV parser, or avoid embedded newlines when producing CSV for an unknown consumer.
Six targets, and the shell one is a security boundary
Every target below escapes different characters for different reasons. Two of them fail in ways that are not formatting problems.
The shell single quote has no escape sequence
Inside single quotes a shell protects everything, including backslashes, so there is no way to write a single quote. The only route is to end the quoted run, emit an escaped quote, and start a new one. The obvious approach of putting a backslash before it does not work and produces a command that runs something other than what you intended. That is command injection, not a formatting bug.
Better still, do not build shell commands by concatenation
Every language has a way to pass an argument array to a process without a shell in between. Use it. The escaping above is for when you genuinely have no choice, and it is a last resort rather than a recommendation.
The SQL form is not a substitute for a parameterised query
Doubling a quote is correct SQL string syntax and it is not a defence. Escaping depends on the connection character set, on the server mode, and on getting it right everywhere rather than almost everywhere. A parameterised query has none of those failure modes, because the value never becomes part of the statement.
CSV keeps a literal newline inside a quoted field
That is legal, and it breaks any parser that splits on lines before parsing quotes, which is most hand-written ones. A field containing a comma, a quote or a line break must be quoted, and an internal quote is doubled. If you are producing CSV for an unknown consumer, that combination is worth avoiding entirely.
Control characters are invisible and significant
JSON escapes them and stays valid. Most other targets pass them through, where they can terminate a value early, corrupt a log line, or make a file appear binary to grep. A NUL byte truncates the value in any C-based consumer. They are almost never intentional in user input, so strip them at the boundary.
What this cannot see
Where the string is going and whether the consumer is strict. It also cannot make an unsafe pattern safe: the shell and SQL forms are correct escapings of a design you should probably not be using. Everything happens in your browser.
More encoding tools
Base64 Encoder & Decoder Both directions, UTF-8 done right Unix Timestamp Converter Seconds or milliseconds? It says which JWT Decoder & Inspector Read the claims, and what is wrong with them URL Encoder and Decoder Which of the two functions you actually want HTML Entity Encoder and Decoder Five characters, not four hundred Hex Encoder and Decoder Bytes, with a hex dump Base32 Encoder and Decoder Two alphabets that decode differently Punycode and IDN Converter The domain that is not what it looks like