How to use the sql escape
- Paste or type the text you want to escape into the Input text box. Multiple lines are allowed and are escaped as one string.
- Choose the SQL dialect that matches your database. The default Standard mode follows the ANSI SQL rule of doubling single quotes. MySQL mode adds backslash escaping for control characters.
- Toggle Wrap in single quotes if you want the result ready to paste directly into a query. Leave it off when you only need the escaped inner text for concatenation.
- Copy the escaped output from the result area. The tool updates instantly as you type or change options, so you can iterate quickly.
How SQL escaping works
SQL string literals are delimited by single quotes. To include a literal single quote inside the string, the SQL standard requires doubling it: O''Reilly represents O'Reilly. This sql escape tool applies that rule by default for Standard, PostgreSQL, SQL Server, and Oracle dialects.
MySQL and MariaDB also support backslash escaping (like C strings). In MySQL mode the tool escapes backslashes (\\), newlines (\n), tabs (\t), carriage returns (\r), the null byte (\0), backspace (\b), double quotes (\"), and the Windows end-of-file character Ctrl+Z (\Z).
PostgreSQL offers dollar quoting ($tag$...$tag$) which avoids escaping altogether; this tool does not generate dollar quotes because they require a unique tag. SQL Server and Oracle follow the standard doubling rule with no backslash processing.
Common escape sequences
The table shows how each dialect treats common characters. Use it as a quick reference when debugging escaped strings.
| Character | Standard / PostgreSQL / SQL Server / Oracle | MySQL / MariaDB |
|---|---|---|
Single quote ' | '' | \' (this tool; '' also works in MySQL) |
Backslash \ | \ (unchanged) | \\ |
| Newline (LF) | literal newline (left as is) | \n |
| Tab | literal tab | \t |
| Carriage return | literal CR | \r |
| Null byte | literal null | \0 |
| Backspace | literal backspace | \b |
| Double quote | " (unchanged) | \" |
| Ctrl+Z (0x1A) | literal | \Z |
When to use each dialect
Standard works for PostgreSQL, SQL Server, Oracle, SQLite, and any ANSI‑compliant database. Choose this when you are unsure or when writing portable scripts.
MySQL is for MySQL and MariaDB. If your MySQL server runs with NO_BACKSLASH_ESCAPES SQL mode, the standard mode is safer because it does not introduce backslashes that the server would treat as literals.
PostgreSQL is listed separately as a reminder that dollar quoting exists; the escaping logic is identical to standard. For complex strings with many quotes, consider dollar quoting manually.
SQL Server and Oracle use standard doubling. No backslash escaping is performed. SQL Server also supports N'...' for Unicode literals; the escaping rules are the same.
Limitations
This tool escapes string literals only. It does not parse full SQL statements, so it cannot protect against injection in identifiers, keywords, or numeric literals. Use parameterised queries (prepared statements) in application code; this tool is for ad‑hoc scripting, data migration scripts, or building dynamic SQL where parameters are not available.
It does not handle:
- Quoted identifiers (double quotes, backticks, brackets)
- Hex or binary literals (
X'...',0x...) - National character literals (
N'...') - PostgreSQL dollar quoting
- MySQL
NO_BACKSLASH_ESCAPESmode (use Standard dialect instead) - Multi-byte character set edge cases where a trailing byte resembles a quote
If you need to escape JSON for storage in a SQL column, see the JSON Escape tool instead.
Worked examples
| Example | Input | Result |
|---|---|---|
| Simple string with quote | Input text: O'Reilly; SQL dialect: standard; Wrap in single quotes: yes | 'O''Reilly' |
| Backslashes and newline | Input text: C:\\Users\\Name / Line2; SQL dialect: mysql; Wrap in single quotes: yes | 'C:\\\\Users\\\\Name\nLine2' |
| Multiple lines | Input text: Line 1 / Line 2 / Line 3; SQL dialect: standard; Wrap in single quotes: no | Line 1 / Line 2 / Line 3 |
FAQ
Does this prevent SQL injection?
No. Escaping is a last resort. Always use parameterised queries (prepared statements) in application code. This tool is for ad‑hoc scripts, migrations, or dynamic SQL where parameters cannot be used. Proper sql escape handling is only one layer of defense.
Why does MySQL mode escape backslashes?
MySQL treats backslash as an escape character by default (unless NO_BACKSLASH_ESCAPES is set). Doubling backslashes ensures a literal backslash is stored. For example, a Windows path C:\Users becomes C:\\Users in the escaped literal.
Can I escape a whole SQL file?
This tool is for string literals only. Pasting a full query will escape the quotes inside it, breaking the syntax. Escape each string value separately before concatenating into the statement.
What about PostgreSQL dollar quoting?
Dollar quoting ($tag$...$tag$) avoids escaping entirely. This tool does not generate it; choose a unique tag manually if you need it. Dollar quoting is especially useful for function bodies and strings containing many single quotes.
Does it handle Unicode?
Yes. Unicode characters are passed through unchanged. Only the characters listed in the table are transformed. The output is UTF-8 compatible and safe for modern databases.
Why is there no SQLite option?
SQLite follows the standard doubling rule. Use the Standard dialect. SQLite also supports the quote() function which does the same thing server-side.
How does this differ from a programming language's escape function?
Language functions like Python's repr() or JavaScript's JSON.stringify() target their own string syntax. SQL has its own rules (doubling quotes vs backslash escapes). This tool implements the database rules, not the language rules.