Free Online SQL Escape Tool
Escape strings for safe use in SQL queries.
Escaping a value is a display and debugging aid, not a replacement for prepared statements. Always bind parameters in application code instead of assembling SQL strings by hand.
About the SQL Escape Tool
A SQL string literal ends at the first unescaped quotation mark. If a value contains an apostrophe, a backslash, or a line break, pasting it directly into a statement can truncate the string, corrupt the value, or open the door to injection. This tool shows how a piece of text looks after the escaping rules of a chosen database have been applied. It is a learning and diagnostic aid: you can see exactly which characters change, compare dialects, and copy the literal into a migration, a fixture, or a manual query.
How the dialects differ
- MySQL and MariaDB: backslashes introduce escapes by default, so a literal backslash becomes two and a single quote becomes
\'or a doubled quote. Control characters such as newline and tab have short forms. - PostgreSQL: standard string literals double the quote. To use backslash escapes for control characters, the literal is prefixed with
E, producing the familiarE'line\n'form. - Standard SQL: the only portable rule is doubling the single quote. Other characters remain literal. A NUL byte has no representation in a text literal and is removed with a warning.
The output panel shows the escaped value ready to paste. The optional example statement places it in a simple
SELECT ... WHERE column = ... shape so the context is obvious. With the quote wrapper disabled,
you get only the escaped inner text, which is convenient when a framework adds its own delimiters. The dialect
selector changes both the escaping rules and the way PostgreSQL literals are prefixed.
A critical caveat: this page does not know your database configuration. MySQL can run with
NO_BACKSLASH_ESCAPES, PostgreSQL can run with standard_conforming_strings disabled,
and drivers may add their own layers of quoting. The output therefore illustrates a common configuration, not
every possible one. When you need safety rather than illustration, use prepared statements, bound parameters,
or your framework's query builder. Those mechanisms send the value separately from the SQL text, so malicious
content is never parsed as syntax.
The escape operation runs in the browser and the input is never uploaded. That makes it safe to test values that look like credentials or personal data, though you should still avoid pasting production secrets into any web page out of habit. Character counts update as you type, and the sample button demonstrates quotes, backslashes, tabs, and newlines in one pass.
How to use this tool
- Select the database dialect that matches your target system.
- Paste the raw value into the input box.
- Review the escaped literal and the example statement.
- Copy the literal or statement, or download the escaped text as a file.
Frequently asked questions
Is the escaped output safe against SQL injection?
Not necessarily. Escaping depends on charset, server mode, and the surrounding syntax. Treat the output as documentation. Real protection comes from prepared statements and parameter binding, not from manual string replacement.
Why does PostgreSQL output start with E?
The E prefix marks an escape string constant, which enables backslash sequences. When the escaped value contains no backslash, the tool omits the prefix because a plain literal is sufficient.
What happens to a null byte?
MySQL can represent it as \0. PostgreSQL text values cannot contain a NUL byte, and standard SQL has no literal form, so the tool removes it and shows a warning. Check whether the value should be stored as binary instead.