SQL Escape Online — Escape SQL String Literals

Escape single quotes and special characters for ANSI SQL and MySQL string literals. For migrations, DBA scripts, and legacy code only — production application code should always use prepared statements.

Input (raw value)

Output (escaped)

What is SQL Escape — and when to use it

SQL escaping is the rule for embedding raw text inside a SQL string literal so the parser does not mistake an apostrophe for the end of the string. The ANSI rule is to double every single quote (' → ''); MySQL also escapes backslashes by default. Prepared statements remain the right answer for production application code — this tool is for the cases where prepared statements are not available: data-fix migrations, DBA scripts, generated DDL, and audits of legacy concatenated SQL.

Use the OpenFormatter SQL escaper to safely embed names, descriptions, JSON blobs, and log messages inside hand-written INSERT and UPDATE statements. Escaping happens entirely in your browser, so customer records and PII never leave the page.

How to SQL escape a literal — 4 steps

Paste the raw value. Drop in the text that needs to live inside a SQL string — names with apostrophes, multi-line descriptions, file paths with backslashes.
Click Escape. The tool doubles single quotes, doubles backslashes, and encodes newline, carriage return, and NUL bytes.
Inspect the output. Every ' becomes '', every \\ stays \\\\, and control characters are written as \\n, \\r, \\0.
Wrap in quotes and embed. Place the escaped string between two single quotes inside your SQL statement. For application code, switch to a parameterised query.

Side-by-side example

Raw input

O'Brien & Sons -- "Premier"
Path: C:\Reports
Multi-line
description

SQL-escaped

O''Brien & Sons -- "Premier"\nPath: C:\\Reports\nMulti-line\ndescription

Wrap the escaped value in single quotes inside your SQL: INSERT INTO vendors (name) VALUES ('O''Brien & Sons …');

ANSI + MySQL Safe

Doubles single quotes per ANSI SQL and doubles backslashes for MySQL's default backslash-escape mode — works across PostgreSQL, SQL Server, Oracle, SQLite, and MySQL.

For Migrations & Scripts

Designed for the gaps where prepared statements do not exist: hand-written migrations, one-off data fixes, generated DDL, and reading legacy concatenated SQL.

Client-Side Only

Substitution runs locally — customer records, PII, and credentials in migration values never reach a server. Verify in DevTools → Network.

Common use cases

check_circleHand-writing data-fix migrations that INSERT or UPDATE literal customer values
check_circleGenerating seed scripts for development databases from real-world examples
check_circleEmbedding JSON blobs and log messages inside SQL TEXT or JSONB columns
check_circleProducing DDL CREATE TABLE statements with default-value string constants
check_circleBuilding DBA repair scripts that cannot use the application's parameter binding
check_circleReading legacy concatenated SQL to verify a value would have been escaped correctly
check_circleRewriting the string portion of LIKE patterns before adding wildcard escaping
check_circlePreparing CSV-derived values for bulk INSERT statements in environments without COPY/LOAD

Escaping vs prepared statements — pick prepared statements

A correctly placed escape chain prevents string-literal injection, but it does not protect identifiers, LIMIT/OFFSET values, or LIKE wildcards — and any developer who later forgets to call the escape function reopens the hole. Prepared statements (parameter binding) push the entire problem down to the database driver, where it is solved once for every dialect. If your code is application-level and the driver supports parameters, use them. This tool is the right answer only when parameters are not on the table — migrations, scripts, and forensic work.

Need to decode escaped SQL?

Reverse SQL string escapes back to the original value, or chain with our other escape tools — all browser-side.

SQL Unescape CSV Escape All Escape Tools

Frequently Asked Questions

Should I use this tool instead of prepared statements?

No — and this is the most important thing on the page. Application code that touches a database in production should use prepared statements (parameter binding) every time. The driver handles escaping, type coercion, and dialect quirks correctly. This tool exists for the cases where parameters are not available: hand-written migrations, one-off DBA scripts, embedded SQL in tools that lack a binding API, and reading or rewriting legacy code that already concatenates strings. Treat it as a forensic and ops aid, not a security boundary.

How does this tool escape a single quote?

Per the ANSI SQL standard, every single quote is doubled: O'Brien becomes O''Brien. When the database parser encounters '' inside a string literal, it emits one literal apostrophe and continues. This works in PostgreSQL, SQL Server, Oracle, SQLite, and MySQL (in either default or ANSI_QUOTES mode).

What about backslash escaping in MySQL?

MySQL by default treats backslash as an escape character inside string literals — so a literal backslash must become \\ and a quote can also be written as \'. The tool doubles backslashes to \\ to remain safe under the default sql_mode. If your server runs with NO_BACKSLASH_ESCAPES set, the doubled backslashes are still correct because the tool also doubles quotes to '' rather than relying on \'.

Why does the tool also escape \n, \r, and the NUL byte?

Multi-line values inside SQL string literals are valid in most dialects but cause subtle bugs in shell heredocs, log parsers, and ETL pipelines that read SQL line-by-line. Encoding \n, \r, and \0 keeps the literal on a single line and avoids accidental statement termination on systems that interpret NUL as end-of-string.

Does escaping prevent SQL injection?

Correct escaping for the right dialect, applied to every string concatenated into a query, with no second-order injection from re-escaped data, prevents string-literal injection. But every one of those qualifiers is a footgun — and none of them protect identifiers (table or column names), LIMIT/OFFSET values, or LIKE wildcards. Prepared statements eliminate the entire class of bugs. Use them.

How do I escape a value for a LIKE pattern?

After escaping the string for SQL, you also need to escape the LIKE wildcards % and _. Pick an ESCAPE character (commonly backslash), prepend it before each literal % or _ in your search term, and add ESCAPE '\' to the LIKE clause. This tool handles only the SQL string escape — LIKE wildcard escaping is a separate step.

What about NULL values?

NULL is not a string and must be written as the bare keyword NULL (no quotes) in SQL. If your value can be NULL, branch in your script: emit NULL when the source is null, otherwise emit a quoted-and-escaped literal. This tool only handles the escape step for non-null strings.

Is my SQL data sent to a server?

No. Escaping is pure string substitution running in your browser. PII, customer records, and credentials in your migration scripts never leave the page. Verify in DevTools → Network — no request fires when you click Escape.