SQL Escape / Unescape
Escape text for SQL string literals or unescape them – per dialect.
SQL Escape and Unescape Online
This SQL escape tool prepares text for use inside a quoted SQL string literal and reverses the escaping with Unescape. Pick a dialect, paste a value such as a customer name, product description, or file path, and copy a literal you can drop between single quotes in an INSERT, UPDATE, seed file, or migration.
Escaping is not SQL injection protection
Let's be clear first: if your application builds queries from user input, the fix for SQL injection is parameterized queries / prepared statements, not escaping. With placeholders like WHERE email = ? or WHERE email = $1, the database driver sends the value separately from the SQL text, so input such as ' OR '1'='1 can never change the query structure. ORMs and query builders do this for you. Escaping by hand is fragile – one missed field, a wrong dialect, or a multibyte charset trick is enough. Use this page for writing literals in scripts, console sessions, and data fixes.
Dialects
- Standard SQL ('') – the ANSI rule used by PostgreSQL, SQL Server, Oracle, SQLite, and also accepted by MySQL: a quote is doubled, so
O'Reilly→O''Reilly. Backslashes stay literal. - MySQL (backslash) – MySQL/MariaDB default mode:
'→',"→",` →\, plus\n,\r,\0and\Z(Ctrl+Z). Don't use it withNOBACKSLASHESCAPES` or on other databases. - LIKE pattern – for search terms in
LIKE: quotes are doubled and the wildcards%and_plus the backslash get a` prefix, so50% off_todaymatches literally. AddESCAPE ''` where the database requires it.
The dialect applies in both directions, so you can unescape a MySQL dump value or a LIKE pattern exactly.
Identifiers are different
Table and column names are not string literals. Quote them with "double quotes" (standard, PostgreSQL), `backticks` (MySQL), or [brackets] (SQL Server) – and never take identifiers from user input without an allow-list.
For CSV imports see CSV Escape / Unescape; for JSON columns use JSON Escape / Unescape.
Frequently Asked Questions
Does escaping protect my application from SQL injection?
Not reliably. The correct fix is parameterized queries (prepared statements), where the SQL text and the values are sent to the database separately: cursor.execute("SELECT * FROM users WHERE name = %s", (name,)) or PreparedStatement.setString(1, name). Manual escaping breaks with the wrong dialect, character set, or a forgotten field. Use this tool for literals in hand-written scripts, migrations, and seed data – not as a security layer.
How do I escape a single quote in SQL?
In standard SQL (PostgreSQL, SQL Server, Oracle, SQLite) double it: 'O''Reilly'. MySQL and MariaDB also accept a backslash, 'O\'Reilly', unless the NO_BACKSLASH_ESCAPES mode is enabled. The doubled form works everywhere, so prefer it for portable scripts.
How do I search for a literal % or _ with LIKE?
Escape them with a backslash and declare the escape character: WHERE code LIKE '50\%\_off' ESCAPE '\'. MySQL and PostgreSQL use backslash as the default LIKE escape, while SQL Server and SQLite need the ESCAPE clause (SQL Server can also use [%]). The LIKE pattern dialect here doubles quotes and escapes %, _, and \.
Why does my PostgreSQL string with \n not contain a line break?
Since PostgreSQL 9.1 (standard_conforming_strings = on) backslashes in '...' are literal. Use an E'...' string for C-style escapes (E'line1\nline2'), or put a real line break inside the quotes. Only the quote needs doubling in standard strings.