How to fix 22025: invalid_escape_sequence in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 29, 2025· 146 views

PostgreSQL error 22025 occurs when a backslash escape sequence in a string literal or bytea constant is not recognized. This happens when backslashes are not properly escaped or when escape syntax is used incorrectly.

Quick fix

Fixes 22025

-- Examples of invalid escape sequences:
SELECT * FROM table WHERE path LIKE 'C:\Users\admin\data'; -- Invalid Windows path
SELECT * FROM table WHERE pattern ~ '\d+\w'; -- Unescaped regex
INSERT INTO data (json_col) VALUES ('{"path": "C:\Users"}'); -- Invalid JSON
  1. Identify the problematic backslash in your query
  2. Double the backslashes in string literals
  3. Use E'' escape string syntax for special characters
  4. Enable standard_conforming_strings for consistency
postgresql — error
-- Examples of invalid escape sequences:
SELECT * FROM table WHERE path LIKE 'C:\Users\admin\data'; -- Invalid Windows path
SELECT * FROM table WHERE pattern ~ '\d+\w'; -- Unescaped regex
INSERT INTO data (json_col) VALUES ('{"path": "C:\Users"}'); -- Invalid JSON
22025: invalid_escape_sequence

What this error means

PostgreSQL uses the backslash character (\) as an escape character for special character sequences. When the database parser encounters a backslash followed by characters that don't form a valid escape sequence (like \n for newline, \t for tab, or \\ for literal backslash), it raises error 22025. This is a syntax-level error that occurs before query execution, indicating the query string itself is malformed. The error commonly appears in LIKE patterns, regular expressions, bytea values, and JSON data with malformed Unicode escapes.

Typical symptoms

  • Query execution fails immediately with '22025: invalid_escape_sequence' message
  • Error occurs before the query is executed on the database
  • Often triggered by dynamically built SQL queries with unescaped paths or patterns
  • LIKE or SIMILAR TO clauses with backslashes cause the error
  • JSON text with incomplete Unicode escapes (like \u without four hex digits) fails
  • Imported data from external files with Windows paths (backslashes) triggers the error

Common causes

  1. Single backslash at the end of a string literal without proper escaping
  2. Backslash followed by an unrecognized character (not a valid escape sequence)
  3. Windows file paths containing backslashes directly in SQL without doubling them
  4. Regular expression patterns with backslashes not properly escaped
  5. JSON strings with incomplete Unicode escape sequences (\u missing hex digits)
  6. Mixing escape string syntax (E'' prefix) with standard strings inconsistently
  7. Incorrect encoding or copy-pasted code from external sources with unescaped backslashes

How to fix "22025: invalid_escape_sequence"

1Identify the problematic backslash in your query

Enable query logging and examine the exact SQL statement that's failing. Look for backslashes in string literals, LIKE patterns, regular expressions, or JSON data.

sql
-- Examples of invalid escape sequences:
SELECT * FROM table WHERE path LIKE 'C:\Users\admin\data'; -- Invalid Windows path
SELECT * FROM table WHERE pattern ~ '\d+\w'; -- Unescaped regex
INSERT INTO data (json_col) VALUES ('{"path": "C:\Users"}'); -- Invalid JSON
2Double the backslashes in string literals

For regular strings, double each backslash (\\) so PostgreSQL treats it as a literal character.

sql
-- Fixed with doubled backslashes:
SELECT * FROM table WHERE path LIKE 'C:\\Users\\admin\\data';

-- Or insert with doubled backslashes:
INSERT INTO table (col) VALUES ('path\\to\\file');
3Use E'' escape string syntax for special characters

When you need to use escape sequences like \n (newline) or \t (tab), prefix the string with E to enable escape sequence interpretation.

sql
-- E'' prefix enables escape sequences:
SELECT * FROM table WHERE data = E'line1\nline2';
SELECT * FROM table WHERE value = E'tab\tseparated';

-- For literal backslash in E'' strings, use double backslash:
SELECT * FROM table WHERE pattern = E'\\d+'; -- Matches one backslash followed by d+
4Enable standard_conforming_strings for consistency

Set standard_conforming_strings to ON (default in PostgreSQL 9.1+) so regular strings treat backslashes literally, and you only need E'' for actual escape sequences.

sql
-- Check current setting:
SHOW standard_conforming_strings;

-- Set for current session:
SET standard_conforming_strings = ON;

-- Or add to postgresql.conf:
standard_conforming_strings = on

With this enabled, you'll be forced to use E'' prefix for escape sequences, making the intent clear.

5Use parameterized queries to avoid escaping issues

The safest approach is to use parameterized queries from your database driver. This lets the driver handle escaping automatically.

javascript
// JavaScript with pg library:
const query = "SELECT * FROM table WHERE path = $1 AND pattern ~ $2";
const values = ["C:\\Users\\admin", "\\d+"];
await client.query(query, values);

// Python with psycopg2:
cursor.execute("INSERT INTO table (json_col) VALUES (%s)", [json_data])

// Ruby with pg:
conn.exec_prepared("query_name", ["C:\\Users\\admin"])
6For JSON data, validate the structure

If error 22025 occurs with JSON, check for incomplete Unicode escapes. Each \u must be followed by exactly 4 hexadecimal digits.

sql
-- Invalid: \u not followed by hex digits
INSERT INTO table (json_col) VALUES ('{"text": "incomplete \u escape"}'); -- FAILS

-- Valid: complete Unicode escape
INSERT INTO table (json_col) VALUES ('{"text": "valid \u0041 escape"}');

-- Or cast to jsonb for validation:
SELECT '{"text": "test"}' :: jsonb; -- Validates JSON format

Advanced notes

When building SQL dynamically in application code, never concatenate user input directly into queries. The parameterized query approach in Step 5 prevents 22025 errors by letting the driver handle all escaping. If you must build SQL strings, use your language's string escaping utilities (e.g., Node.js template literals with proper escaping, Python's psycopg2.sql module). The standard_conforming_strings setting became the default in PostgreSQL 9.1. Older databases may have it disabled, forcing you to use E'' or double-escape even in normal strings. Migrating to a modern PostgreSQL version is recommended. For regular expressions in LIKE or ~ operators, remember that regex special characters also need escaping: use E'\\d+' to match literal \d+, or E'[0-9]+' for digits. JSON parsing is stricter in jsonb type than json type—jsonb validates Unicode escapes more rigidly, making encoding issues obvious earlier.

Frequently asked questions

What does "22025" mean?
PostgreSQL uses the backslash character (\) as an escape character for special character sequences. When the database parser encounters a backslash followed by characters that don't form a valid escape sequence (like \n for newline, \t for tab, or \\ for literal backslash), it raises error 22025. This is a syntax-level error that occurs before query execution, indicating the query string itself is malformed.
How do I fix "22025"?
PostgreSQL error 22025 occurs when a backslash escape sequence in a string literal or bytea constant is not recognized. This happens when backslashes are not properly escaped or when escape syntax is used incorrectly.
What causes "22025"?
Single backslash at the end of a string literal without proper escaping Backslash followed by an unrecognized character (not a valid escape sequence) Windows file paths containing backslashes directly in SQL without doubling them
Is the "22025" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading