How crossword editors test and refine puzzle submissions

Close-up of a senior woman editing a manuscript at a desk with a green marker indoors.

Photo by Ron Lach on Pexels

How crossword editors test and refine puzzle submissions is a question most solvers never think to ask. You pick up the newspaper, fill in the grid, and move on. But between a constructor's first draft and that finished puzzle sits a process involving test solvers, database checks, editorial rewrites, and sometimes weeks of back-and-forth negotiation. It's painstaking work, and it's the main reason a published puzzle feels smooth while a rough submission does not.

What lands on an editor's desk

A constructor submits a puzzle as a completed grid alongside a full set of clues. Major outlets like The New York Times Crossword receive hundreds of submissions every month, most of which are rejected before the editing phase begins. The first filter is structural: does the grid meet house rules on symmetry, black-square count, word length minimums, and the ratio of theme entries to fill? A grid failing those criteria goes back without further review.

Submissions that pass the structural check move into the editorial queue. That queue can stretch months long at large publications, so a constructor may wait six months before receiving any substantive feedback. At smaller outlets the turnaround is faster, but the scrutiny is no less careful.

The fill audit: hunting ugly crossings

The first substantive test an editor runs is a fill audit. Fill refers to the non-theme words packed around the theme entries, and poor fill is the most common flaw in otherwise strong puzzles. Editors check for:

  • Crosswordese: tired three-letter standbys like ESNE, ETUI, or OLEO that solvers tolerate but no one enjoys.
  • Partials: fragments such as "A LOT" or "IN A" that appear as standalone answers.
  • Obscure proper nouns crossing other obscure proper nouns, creating what editors call a "Natick" (a crossing so obscure that guessing becomes the only option).

Many editors use software to flag potential problems. Crossword construction tools like Cruciverb maintain community wordlists with freshness scores attached to entries, so editors can see at a glance whether a word has been used thirty times in the past five years or barely at all. A word with an extremely high usage count gets flagged for replacement unless the clue is fresh enough to redeem it.

Clue testing: the human pass

Software catches structural problems. Humans catch tone. After the fill audit, the editor reads every clue aloud. This sounds fussy, but it's how editors catch clues that are technically accurate yet feel flat, misleading without purpose, or simply unpleasant to parse.

Clue testing focuses on three things. First: fairness. A good crossword clue should have exactly one defensible answer, and a solver who gets the crossing letters should land on that answer without ambiguity. Second: misdirection. The best clues point the solver toward the wrong meaning first, then snap into focus when the answer appears. Third: consistency of difficulty. A Tuesday puzzle in the New York Times is calibrated to be harder than Monday but easier than Wednesday, and clue difficulty must hold that register across all entries, not just the theme.

The editor rewrites clues that fail any of those tests. Some constructors get back a puzzle where 30 percent of the clues have been replaced. That's not a failure on the constructor's part; it reflects how thorough the editorial layer is.

Test solving: the gold standard

Test solving is the closest the editorial process gets to a controlled experiment. The editor sends the puzzle, without answers, to a small group of test solvers. These are typically experienced constructors or longtime enthusiasts who can finish a themeless grid quickly and articulate exactly where they slowed down and why.

Test solvers note every square where they paused, every clue they found unfair, and every answer that felt stale or dated. They report completion time, which helps calibrate day-of-week difficulty. A Tuesday puzzle solved in four minutes by an expert solver is probably too easy for a Thursday slot. A grid with two or three "natick" complaints from different solvers gets sent back for a fill revision regardless of how the editor felt about it personally.

This is the stage that catches problems no single editor can find alone. Constructors who develop strong themes sometimes fill the surrounding grid in a rush, and test solvers reliably surface the resulting rough patches in the corners.

Theme verification and freshness checks

Theme entries receive their own layer of verification. An editor confirms that each theme answer is accurate, unambiguous, and culturally legible to the puzzle's target audience. A theme built around slang that peaked in 2019 may feel dated to solvers encountering the puzzle in 2026. References tied to a specific news cycle risk feeling stale if the puzzle runs six months after submission.

Editors also cross-check themes against the publication's archive. If a nearly identical theme ran two years ago, the new puzzle needs to offer something genuinely distinct: a fresh angle, a tighter set of entries, or a revealer that reframes the concept. Constructor archives are a useful reference here, both for editors and for constructors doing their own pre-submission research.

The revision loop

After test solving and clue review, the editor sends notes back to the constructor. This is where the collaboration either clicks or stalls. Good editors explain the reasoning behind each change request rather than just issuing directives. A note that says "Corner C feels stale" is less useful than "OREO crossing ETUI in the northeast makes two of the least-loved three-letter entries adjacent; can you open that corner differently?"

Constructors respond by revising the grid, the clues, or both. A second round of test solving sometimes follows if the structural changes are significant. The cycle repeats until the editor is satisfied.

Not every puzzle survives the loop. Some submissions get revised three times and still don't reach publication. The editor kills them, usually with a brief explanation so the constructor can apply the feedback to future work. It's a hard outcome, but it's what keeps the published corpus clean.

Final copy editing and fact-checking

The last pass is the least glamorous and the most consequential. A copy editor checks every clue for factual accuracy, spelling, and punctuation. Clues referencing dates, titles, record holders, or geographic facts get verified against primary sources. A clue that was accurate at submission may need updating if circumstances changed during the months it spent in the queue.

Fact errors that reach print are embarrassing in any publication. In a crossword they're worse: the wrong answer may be the only answer that fits the grid, trapping solvers in a corner with no exit. Getting the construction right from the start reduces but doesn't eliminate this risk, which is why the final fact-check exists as a distinct step.

Once the copy edit clears, the puzzle gets formatted for print and digital delivery, assigned a run date, and filed. The constructor receives a contract and, eventually, a byline. The solver receives a grid that looks effortless. The gap between those two things is the editorial process.