TitleCasePro logo TitleCasePro

Methodology

Written by , who publishes as scortier · Last reviewed

Most title case tools give you an answer and no reasoning. This page is the reasoning. It explains where each style's rules come from, exactly how the engine turns a string into a capitalized title, which decisions the engine makes on your behalf when a style guide is silent or ambiguous, how those decisions are locked down by tests, and how to tell us when we get one wrong.

Where the Rules Come From

TitleCasePro supports nine styles. Six are defined by a published manual, and five of those are pinned here to a specific numbered edition. The AP Stylebook is revised on a rolling basis rather than issued as numbered editions, and the remaining three — New York Times house style, Wikipedia's community-maintained Manual of Style, and the email subject line convention — have no edition or publication year at all. Where that is the case we say so rather than inventing a citation. Every style guide page on this site prints its own source block, and the same data drives the table below.

StyleSource
APA Publication Manual of the American Psychological Association, 7th edition (2020)
Chicago The Chicago Manual of Style, 17th edition (2017)
AP The Associated Press Stylebook
MLA MLA Handbook, 9th edition (2021)
Bluebook The Bluebook: A Uniform System of Citation, 21st edition
AMA AMA Manual of Style: A Guide for Authors and Editors, 11th edition
NY Times New York Times house style
Wikipedia Wikipedia Manual of Style — Capital letters (MOS:CAPS) and Article titles (WP:TITLEFORMAT)
Email No published manual — professional email subject line convention (sentence case)

For each style, the process was the same. Read the capitalization section of the manual. Extract the rule it states as a decision procedure — not as prose, but as something a program can execute on one word at a time. Identify what the rule depends on: word class (article, coordinating conjunction, preposition), word length, and position in the title. Then encode that as a lowercase word set plus a set of positional overrides, and write tests for the titles most likely to expose a mistake.

The result is that the styles differ from each other in a small number of well-defined ways, and the differences reduce to which preposition list a style's lowercase set is built from. MLA is the only style here that lowercases prepositions of any length, so it is the only one that uses the full preposition list. Chicago and Bluebook use a four-letter cutoff — prepositions of four letters or fewer stay lowercase, longer ones are capitalized — so their sets use the short-preposition list. APA and AP both draw the line at four letters in the other direction: they lowercase only prepositions and conjunctions of three letters or fewer, so both are built from the same tiny-preposition list and their lowercase sets are byte-identical. APA and AP therefore always produce the same title case. New York Times is not a length rule at all but a fixed nine-word list of short prepositions, which is why it capitalizes Via, Off, Out and Per where APA and AP lowercase them. AMA capitalizes every word, so its lowercase set is empty. Wikipedia and email subject lines are sentence case, handled by their own rule modules rather than by the shared title-case helper.

One consequence worth stating plainly: the word lists are the rules. A missing word is a wrong answer. Early in this project the four-letter prepositions over, from, into, like, onto, and down were absent from the short-preposition list, which made Chicago and Bluebook capitalize them incorrectly. That is exactly the class of bug the test suite now exists to catch.

How the Engine Works

The engine is plain TypeScript with no dependencies, no network calls, and no framework. It runs in your browser; your text never leaves your device. Conversion happens in three stages.

1. Tokenise

The input string is split on whitespace, and each token is separated into a leading punctuation prefix, a bare word core, and a trailing punctuation suffix. Splitting punctuation off first is what lets a title like "the end." be evaluated on the word end rather than on end., and it guarantees the punctuation is put back exactly as you typed it. Apostrophes — straight and curly — are treated as part of the word, so don't is one token, not two.

Each token is then annotated with the facts a rule needs: its index; whether it is the first word; whether it is the last word; whether the previous token ended in a colon; whether it looks like an acronym (two or more characters, all uppercase); and whether it is mixed case in the iPhone or eCommerce pattern.

2. Apply the style's rule module

Each style has its own module, and the engine dispatches to it by style id. Six of the nine styles are thin wrappers around a shared title-case helper: they hand it their lowercase word set and a function that explains, in words, why a given word was lowercased. AMA, Wikipedia, and email implement their own loop because their rules are not "capitalize except for this set."

The helper evaluates each word in a fixed order of precedence: user overrides first, then acronyms, then mixed-case brand names, then hyphenated compounds, then position rules (first word, last word, word after a colon), then the style's lowercase set, and finally the default — capitalize.

3. Reconstruct and explain

Every word is returned as a token carrying its original text, its output text, a plain-English reason, and whether it changed. The visible title is those outputs joined with single spaces; the "Explain" panel in the tool is the same tokens rendered as a list. Nothing in the explanation is generated separately from the result, so the explanation cannot disagree with the output.

How Ambiguous Cases Are Decided

Style manuals are written for human editors, so they leave gaps that a program must fill. These are the decisions TitleCasePro makes, and why.

First and last word

In every title-case style, the first and last words are capitalized regardless of word class. This overrides the lowercase set: Reading between the Lines in MLA becomes The Lines We Read Between — Between takes a capital at the end even though MLA lowercases prepositions of any length. The engine treats this as a positional rule evaluated before the word-set lookup.

Words after a colon

The word following a colon starts a new unit and is capitalized in all styles, including the two sentence-case styles. The engine detects this at tokenisation time by marking any token whose predecessor ended in a colon — including a colon that sits inside a closing quotation mark — and the rule fires before the lowercase set is consulted.

Hyphenated compounds

Hyphenated words are the least consistent area across manuals. TitleCasePro splits the compound on hyphens and applies the style's own rules to each part: the first part follows the position rules, and later parts are lowercased only if they are in the style's lowercase set. So Self-Report capitalizes both halves, while a compound ending in a small function word keeps that word lowercase. This is a deliberate, uniform choice applied identically in every style; where your publisher's house style differs on a specific compound, adjust that word by hand after converting.

Acronyms and all-caps words

A token of two or more characters that is entirely uppercase is treated as an acronym and passed through untouched, so NASA, HTML, and PDF survive conversion. The trade-off is that a title typed in all caps looks like a string of acronyms. That is why the tool has a "keep all-caps words" toggle, on by default — switch it off and all-caps input is re-cased normally.

Mixed-case brand names

A word whose first letter is lowercase but which contains an internal capital — iPhone, eBay, iOS — is preserved exactly as typed. No style manual wants Iphone, and no algorithm can restore the intended casing once it is lost, so the safe behaviour is to leave it alone.

Proper nouns in sentence-case styles

Wikipedia and email subject lines are sentence case: first word and proper nouns capitalized, everything else lowercase. Reliable proper-noun detection is a natural-language problem, not a rule problem, and guessing would silently damage titles. TitleCasePro therefore uses your input as the signal: a word you typed with a capital letter stays capitalized; a word you typed in lowercase is lowercased. Type paris and you get paris; type Paris and you get Paris. This is the one place where the tool's output depends on the casing of your input rather than only on its words.

How Correctness Is Verified

Rules that are not tested drift. Every rule described above is pinned by unit tests that run with npm run test (Vitest) before any change ships.

As of this review, the capitalization engine's own suite in src/lib/capitalization/__tests__/ is 5 test files containing 74 tests, covering the engine and its nine rule modules, the case converters, and smart-quote handling. Across the whole site — the capitalization engine plus the readability, keyword density, extraction, text cleaning, unscrambler, and Wordle utilities behind the other tools — the suite is 15 test files containing 407 tests. All of them pass on the reviewed commit; these counts were produced by running the suite, not copied from documentation.

The tests are assertions about output, not about implementation. Each one pins a specific input title in a specific style to the exact string that style should produce — the cases that historically broke (four-letter prepositions, first and last word overrides, words after a colon, acronyms, hyphenated compounds) plus the ordinary cases that would reveal a careless refactor. If a rule change alters a result it should not have altered, a test fails and the change does not ship.

Two further checks reduce the chance of published content disagreeing with the tool. The examples table on every style guide page is generated at build time by calling the same capitalize() function the tool calls, so the examples you read cannot drift from the output you get. And the comparison view runs one title through all nine styles in a single pass, which makes cross-style inconsistencies visible immediately.

Limits of This Tool

Being useful requires being honest about what a capitalization engine cannot do. It cannot resolve grammatical ambiguity — whether up in a given title is a preposition or part of a phrasal verb changes the correct answer in Chicago, and only a reader who understands the sentence can tell. It cannot know your publisher's house exceptions. It does not apply the italicization, abbreviation, or ordering rules that legal and academic citation formats require around a title. And where a manual states a preference rather than a rule, TitleCasePro implements one consistent reading of it. Treat the output as a fast, consistent first pass — then apply your own judgment, and your publisher's.

Report a Rule You Think Is Wrong

Corrections are welcome and are the fastest way this tool improves. Email workwithscortier@gmail.com with:

A report with a section number is acted on quickly, because it can be checked against the source and turned directly into a test. A report without one still helps, but takes longer to verify. Confirmed errors are fixed in the rule module, locked in with a new test case, and reflected on the affected style guide pages; the review date at the top of each page shows when it was last checked.

Related Pages