Classification
Unicode look-alike quotes in SQL string literals
Origin
Queries copied from Word, Google Docs, wikis, documentation, chat
Target
MySQL, PostgreSQL, SQL Server, SQLite clients

The problem

SQL is strict about quotes. A string literal must be wrapped in straight single quotes ('), and identifiers in straight double quotes or backticks. When you copy a query out of a Word document, a Google Doc, a wiki, or a documentation page, the editor has often already “improved” your straight quotes into curly typographic ones — ‘ ’ “ ”. To the database engine those are not quote characters at all. They’re just unexpected symbols in the middle of your statement.

The error a database actually throws

The query looks correct. The engine disagrees, and its message points at a location rather than naming the real cause:

Before · pasted from a doc into your SQL client
SELECT * FROM users WHERE status = ’active’;
curly quotes where straight ones belong
Before · what the engine reports
mysql> ERROR 1064 (42000): You have an error in your SQL
syntax; check the manual near '’active’' at line 1

postgres=# ERROR: syntax error at or near "’"
syntax error · caret on a “normal”-looking quote

Both engines report a syntax error near a quote that looks completely ordinary. Nothing in the message says “this apostrophe is the wrong Unicode character,” which is why these can cost real debugging time.

Why SQL makes this especially maddening

  • The query ran fine where you copied it. In the doc it was just text, so the curly quotes never mattered until the database tried to parse them.
  • The error blames syntax, not characters. You reread your JOINs and WHERE logic instead of inspecting a single apostrophe.
  • It can fail silently instead of loudly. If a curly quote lands inside a value rather than delimiting it, the statement may run and store the wrong data — a bug you find much later.

The fix

Run the query through Straighten Quotes (key 5) before you paste it into your client. Every curly single and double quote becomes its straight, code-safe equivalent, and typographic dashes and ellipses are normalized at the same time:

After · Straighten Quotes, then run
SELECT * FROM users WHERE status = 'active';
After · the engine’s response
mysql> Query OK, 42 rows returned (0.01 sec)
valid literal · runs first try

With straight quotes restored, the literal delimits correctly and the query executes as written.

Where else it bites

The same curly-quote trap catches shell one-liners, JSON embedded in a query, config values, and quoted identifiers — anywhere a program expects a straight ' or " and a rich-text editor quietly supplied a typographic one. Making a Straighten Quotes pass a reflex whenever code leaves a document saves the debugging session before it starts.

The clean fix

Before a query copied from any rich-text source goes into your database client, run it through cleanplaintext.com and press Straighten Quotes. The literals come out delimited by the characters the parser actually expects.