SQL String Escape

You have a user-submitted value — O’Reilly & Associates — and you need to store it in a database. If you paste it directly into a SQL string literal without escaping, the single quote breaks the statement and you have a potential SQL injection vector. This tool escapes the value correctly for your target database dialect, ready to paste into a SQL string.

Why SQL String Escaping Matters

SQL injection is consistently ranked in the OWASP Top 10. It occurs when attacker-controlled input is concatenated into a SQL statement without proper escaping, allowing the attacker to terminate the intended string and inject arbitrary SQL.

-- Dangerous: user input = O'Reilly
SELECT * FROM authors WHERE name = 'O'Reilly';
-- Syntax error. Attacker could inject: '; DROP TABLE authors; --

-- Safe: escaped with standard SQL doubling
SELECT * FROM authors WHERE name = 'O''Reilly';

String escaping is a second line of defense. The first line is parameterized queries (prepared statements), which prevent injection structurally by keeping SQL code and data separate. This tool is for situations where you are writing raw SQL by hand, constructing queries in environments without parameterized query support, or generating SQL scripts.

Escaping Rules by Dialect

Standard SQL (ANSI SQL-92)

Standard SQL uses a single escaping rule for string literals: a single quote (') within a string is represented by two consecutive single quotes (''). No backslash escaping is defined.

SELECT 'O''Reilly'     -- produces: O'Reilly
SELECT 'It''s a test'  -- produces: It's a test

MySQL / MariaDB

MySQL supports two methods: the ANSI doubling method ('') and a backslash-based escaping system. The backslash method is the MySQL default when NO_BACKSLASH_ESCAPES mode is not set.

MySQL escape sequences:

Important: MySQL’s NO_BACKSLASH_ESCAPES SQL mode disables backslash escaping and makes MySQL behave like standard SQL. Always check which mode your MySQL server is running. This tool escapes for the default mode (backslashes enabled).

PostgreSQL

PostgreSQL follows the SQL standard: single quotes are doubled (''). Backslash is not treated as an escape character in regular string literals by default.

For strings containing actual backslash characters, PostgreSQL offers escape string constants prefixed with E:

SELECT E'Line 1\nLine 2';   -- E prefix enables backslash escapes
SELECT 'Line 1\nLine 2';    -- backslash is literal (no E prefix)

The standard_conforming_strings setting (on by default since PostgreSQL 9.1) controls whether backslashes in regular strings are treated as escapes. When on (the default), '\' is two characters — a backslash and a single quote — not an escaped quote. Use the E-prefix form or dollar-quoting for backslash escape sequences.

The “Wrap in Quotes” Option

When the Wrap in quotes checkbox is enabled, the tool surrounds the escaped value with single quotes, producing a complete SQL string literal ready to paste into a statement:

WHERE name = 'O''Reilly'

Without wrapping, you get just the escaped value content:

O''Reilly

Disable wrapping when you are assembling the quotes separately or using a string concatenation function.

LIKE Wildcards: % and _

In SQL LIKE patterns, % matches any sequence of characters and _ matches any single character. If you need to match a literal % or _, they must be escaped — but the escaping syntax varies by database:

Standard SQL / PostgreSQL: Use ESCAPE clause with a custom escape character:

WHERE name LIKE '50\%' ESCAPE '\'

MySQL: Escapes \% and \_ natively (with backslash escaping enabled).

This tool escapes % and _ for MySQL mode only (as \% and \_). For standard SQL and PostgreSQL, handle these separately using the LIKE ESCAPE clause.

Parameterized Queries: The Right Solution

For production code, always use parameterized queries (also called prepared statements or bind parameters). They completely prevent SQL injection by separating the SQL structure from the data values — the database driver handles the escaping automatically and correctly.

Examples:

# Python (psycopg2 - PostgreSQL)
cursor.execute("SELECT * FROM authors WHERE name = %s", (name,))

# Python (sqlite3)
cursor.execute("SELECT * FROM authors WHERE name = ?", (name,))

// Node.js (pg - PostgreSQL)
await client.query('SELECT * FROM authors WHERE name = $1', [name]);

// Node.js (mysql2)
await connection.execute('SELECT * FROM authors WHERE name = ?', [name]);

// Java (JDBC)
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM authors WHERE name = ?");
stmt.setString(1, name);

Use this tool for constructing static SQL scripts (migrations, seed files, one-off queries) or for learning and debugging, not as a substitute for parameterized queries in application code.

Frequently Asked Questions

Which SQL mode should I use for MySQL 8? Use MySQL mode. MySQL 8 still uses backslash escaping by default unless NO_BACKSLASH_ESCAPES is enabled. If you are unsure about your server’s SQL mode, run SELECT @@sql_mode; and check whether the output contains NO_BACKSLASH_ESCAPES.

Does PostgreSQL need backslash escaping for single quotes? No. In standard PostgreSQL with standard_conforming_strings on, a single quote is escaped by doubling it (''), not with a backslash. A backslash before a quote in a regular string literal is just two separate characters.

What about NULL values in SQL? SQL NULL is not a string value — it is the absence of a value. To insert NULL, use the SQL keyword NULL without quotes: INSERT INTO t VALUES (NULL). Never put NULL inside a string literal.

Should I escape integers, booleans, or dates? No. Numeric values should be validated and cast to the appropriate type, not string-escaped. Only string values (those that will appear inside SQL single quotes) need string escaping.

Related Tools

• JSON Escape / Unescape — escape strings for JSON contexts
• SQL Formatter — format and beautify SQL queries
• XML Escape / Unescape — escape reserved characters for XML and HTML
• URL Encoder / Decoder — percent-encode strings for use in URLs