SQL Unescape Online — Decode SQL Strings

Decode ANSI doubled quotes and MySQL backslash escape sequences from SQL string literals back to their original characters. Read pg_dump, mysqldump, and migration values without the SQL noise — 100% in your browser.

Input (escaped)

Output (decoded)

What is SQL Unescape?

SQL unescape reverses the escape rules used inside SQL string literals. ANSI SQL doubles single quotes ('' → '); MySQL in default mode also uses backslash escapes (\\\\ → \\, \\n → newline). Unescape returns the exact bytes that were originally stored in the column — useful for reading dumps, migrations, query logs, and replay traces.

When you grep a pg_dump file or trail through a mysqldump for a customer record, the value comes back wrapped in quotes with apostrophes doubled and backslashes paired up. The OpenFormatter SQL unescape tool restores the original text in your browser — no upload, no account, no rate limits — so you can safely process dumps that contain PII.

How to SQL unescape a literal — 4 steps

Locate the value. In a dump or migration, find the column value — the text between the two surrounding single quotes.
Paste the content (no outer quotes). Copy only the text between the quotes into the Input panel. Including the outer quotes adds spurious characters at the start and end.
Click Unescape. The tool reverses '', then \\n/\\r/\\0, then \\\\ — in that order — to faithfully reconstruct the stored bytes.
Copy the result. The output is the exact original value. Use it for forensic analysis, reporting, or pasting into a downstream tool.

Side-by-side example

Escaped (from dump)

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

Decoded (original value)

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

Dump-Aware

Handles the conventions used by pg_dump, mysqldump, SQL Server BCP, and SQLite .dump exports — both ANSI quote doubling and MySQL backslash escapes.

Correct Decoding Order

Decodes '' first, control-character escapes second, and \\ → \ last — preventing the common bug where backslash-doubling silently corrupts adjacent escape sequences.

Client-Side Only

Substitution runs locally — customer records and PII extracted from production dumps never leave the browser. Verify in DevTools → Network.

Common use cases

check_circleReading the original column values from a pg_dump or mysqldump file
check_circleExtracting log messages stored as TEXT columns from SQL dumps
check_circleInspecting JSON blobs serialized into a JSONB column shown in escaped form
check_circleReplaying production INSERT statements into a staging environment after manual edits
check_circleDecoding the parameter values in a logged slow query
check_circleReading file paths and Windows registry strings stored in legacy databases
check_circleInspecting Base64 payloads embedded in escaped TEXT columns
check_circleDecoding migration seed data before importing into a non-SQL system

Why decoding order matters

If you collapse \\\\ → \\ first, you can accidentally turn the literal sequence \\\\n (a stored backslash followed by the letter n) into a newline. Reversing the operations in the same order they were applied during escaping — quotes first, control characters second, backslashes last — keeps every literal byte exactly where it belongs. The tool follows this order so dumps with embedded backslash literals round-trip correctly.

Need to escape instead?

Re-escape values for embedding inside SQL literals, or chain with our other escape tools — all browser-side.

SQL Escape CSV Unescape All Escape Tools

Frequently Asked Questions

Which SQL escape conventions does this tool decode?

Both major dialect families. ANSI SQL (PostgreSQL, SQL Server, Oracle, SQLite) doubles single quotes — '' represents one literal apostrophe. MySQL in default sql_mode also uses backslash escapes — \\, \n, \r, \0, \'. The tool reverses both: '' becomes ', \\ becomes \, and the control-character forms become real newlines, carriage returns, and NUL bytes.

How do I extract a value from a SQL dump for unescaping?

In a pg_dump or mysqldump INSERT statement the value lives between two single quotes. Copy the content between those quotes — not the surrounding quotes themselves — into the input. Run the tool and you have the original stored value. The same procedure works for migration files and seed scripts.

What is the order of operations when decoding?

The tool replaces '' first, then the control-character escapes (\n \r \0), and only then collapses \\ to \. Doing backslashes last prevents accidentally double-decoding sequences like \\\n, where the original literal was a backslash followed by an n — the doubled backslash protects the literal n from being interpreted as a newline escape.

Why does my output still contain backslashes?

You probably had a literal backslash in the original value. Doubled backslashes in the dump represent one real backslash in the data. After decoding, expect to see single backslashes in file paths, regex patterns, or stored serialized blobs.

Will this decode dollar-quoted PostgreSQL strings?

No. Dollar-quoted strings ($$ … $$ or $tag$ … $tag$) bypass the escaping rules entirely — the content between the dollar markers is taken literally. You do not need to unescape it; you just strip the markers. The tool handles the standard quote-doubled and backslash-escaped string conventions, not dollar quoting.

Can I decode an entire INSERT statement at once?

Paste only the value portion — the text between the surrounding single quotes — for each column. Pasting the whole statement (with the keyword INSERT, parens, and commas) produces a result that mixes SQL syntax with decoded text, which is rarely what you want. For multi-row scripts, decode each value individually.

How does this handle E'…' escape-string literals?

PostgreSQL escape-string literals (prefixed with E) accept C-style backslash escapes including \n, \r, \xHH, and \uXXXX. This tool decodes the common cases (\n, \r, \0, \\) but not the hex or Unicode forms — for those, use a JavaScript or JSON unescape tool, which natively supports \uXXXX.

Is my SQL data sent to a server?

No. Decoding is pure string substitution running in your browser. Customer records, PII, and credentials extracted from SQL dumps never leave the page. Verify in DevTools → Network — no request fires when you click Unescape.