Smart Quotes vs Straight Quotes: When to Use Curly Quotes (and When They Break Your Code)

There are two kinds of double quote on your screen right now, and most people never notice the difference until something goes wrong. One is the vertical typewriter mark your keyboard types by default: the same glyph for opening and closing. The other is the directional, curled pair you see in a printed book, where the opening mark leans one way and the closing mark leans the other. They look almost identical at a glance. They are different Unicode characters, and which one you want depends entirely on where the text is going.

This guide walks through that decision: when prose wants curly quotes, when code demands straight ones, how apostrophes and em dashes fit in, and how to clean a paragraph that someone pasted out of a word processor without checking. If you just want to flip a block of text right now, the Smart Quotes Converter does it in one click and runs entirely in your browser.

Straight quotes look plain in prose

Open any novel, magazine, or well-set web page and look at the quotation marks. They curl. A line of dialogue opens with a left-leaning mark and closes with a right-leaning one, the same way the page printer set type a century ago. This is not decoration; it is the difference between text that reads as finished and text that reads as a draft.

Straight quotes are what your keyboard produces, and in a body of prose they read as plain and slightly unfinished, the visual equivalent of a monospaced font where one isn't called for. A sentence like she said "yes" with vertical marks looks like raw output. The same sentence with curly marks looks like it came out of an editor. Readers rarely name the difference, but they feel it. If you publish articles, write captions, or set anything that another human reads for pleasure, curly quotes are the correct choice and straight quotes are a small, persistent signal of carelessness.

Curly quotes break code

Now flip the situation. Programming languages, shells, and data formats expect straight ASCII quotes and nothing else. A curly quote is a separate Unicode character, so the moment one slips into a string literal, a JSON value, or a terminal command, the parser either throws a syntax error or, worse, silently fails to match the string you thought you typed.

This is the trap that catches people who draft snippets in a word processor or a note-taking app with smart quotes turned on. You write SELECT name FROM users WHERE city = "Beijing", the app helpfully curls both quotes, you paste it into a database client, and the query dies on a character you can't even see. The same happens with a JSON config where a curly quote breaks the value, or a copied shell command where the smart apostrophe in don't is no longer the apostrophe bash recognizes. A good converter warns you when the input looks like code, but the real fix is to run the text in reverse and collapse every curly mark back to plain ASCII before it touches a parser.

Apostrophes and dashes deserve the same care

The apostrophe is the most common typographic mistake, because it sits at the seam between the two systems. The correct apostrophe in it's, don't, and '90s is always the right single quotation mark, the closing curly glyph, never the opening one. Word processors get this wrong precisely when the apostrophe starts a word: type '90s and many apps insert an opening quote, curling the wrong direction. That is the difference between professional typesetting and a near miss, and it is exactly the case a context-aware converter handles correctly.

Dashes are the other quiet upgrade. An em dash is the long one for a break in a sentence; an en dash is shorter and joins ranges like 1–9; an ellipsis is a single character standing in for three dots, not three periods mashed together. All three are awkward to type directly, so the convention is to write a double hyphen for the en dash, a triple hyphen for the em dash, and three plain dots for the ellipsis, then let the tool swap in the right glyphs. One caution worth repeating: a double hyphen in code can be a CLI flag like --verbose or an SQL comment, so leave smart punctuation off when the text is source rather than prose.

A worked example: straight to curly and back

Take this raw line, typed with a plain keyboard:

"It's a 1-9 range," she said -- then paused...

Run it through smart-quote conversion with smart punctuation on, and you get:

"It's a 1–9 range," she said — then paused…

The opening double quote curls inward, the closing one curls the other way, the apostrophe in It's becomes the right single quotation mark, the -- becomes an en dash, the standalone -- becomes an em dash, and the three dots collapse into one ellipsis character. That is publication-ready prose.

Now suppose that curled line ended up inside a config string and you need clean source again. Flip the direction to curly-to-straight, run it back, and every smart quote and apostrophe collapses to plain ASCII, the ellipsis returns to three dots, and the dashes can stay or revert depending on your settings. The text parses again. The round trip is lossless enough for daily work, which is what makes it safe to keep curly quotes in your published copy and straight quotes in your code without maintaining two separate documents by hand.

Cleaning text that someone else pasted

The messiest real-world case is a document assembled from several sources. Someone drops in a quote from an email, another from a PDF, a third typed straight into the editor, and now half the quotation marks curl and half don't. Hunting line by line for the one stray straight quote in a curly paragraph is exactly the kind of tedious work that gets skipped, and the inconsistency ships.

The fix is to run the whole document through in one direction so every mark matches a single style, then paste the uniform result back. I keep this in my own writing flow: I draft in a plain editor where every quote is straight and fast to type, and right before publishing I paste the whole piece through the converter once. Everything comes out matched, the apostrophes land on the correct glyph, and I never think about it again. When the same text also has stray whitespace or invisible characters from a paste, I follow up with the Text File Cleaner to strip the rest. Two passes, and a document stitched from five sources reads like it was set by one hand.

Pick the right quote for the destination

The whole thing reduces to a single question: who or what reads this text next? If it is a person reading prose, use curly quotes, the right single quotation mark for apostrophes, and real dashes. If it is a parser, a shell, or a database, use straight ASCII and nothing fancier. The mistake is never the quote style itself; it is using the wrong one for the destination. Keep both within reach, convert in whichever direction the moment calls for, and the same paragraph can be a polished sentence in your CMS and a clean string in your code without you ever editing it twice by hand.

---

Made by Toolora · Updated 2026-06-13