In this guide
- Keep the title and its URL separate
- Choose sentence case or title case
- Check names and acronyms after changing case
- Know when to capitalize every word
- Make one short and readable path segment
- Choose a policy for accents and other scripts
- Use a different format for identifiers and files
- Don't use a slug as a URL-encoded value
- Check uniqueness before setting the path
- Preserve established URLs during a title edit
- Run a small publishing check
Keep the title and its URL separate
A title tells a reader what they will get. A slug is the short label in the path that lets someone recognize the page when they see a link. They can share words without sharing punctuation, capitalization or length. For example, A Beginner’s Guide to PDF Forms: What to Check Before Sending can live at /guides/check-pdf-forms/. The title provides the context; the path gives someone enough information to recognize the link when a chat application shows only the address.
Write the title for the person who will read it first. Keep your original in a separate tab or a draft, especially if it contains an acronym, a person's name or an unusual product spelling. Generate a second version for the URL. Don't run your visible heading through the slug tool and then try to reconstruct the title from the output: apostrophes, case and sometimes accents will already have been lost. Even two headings that are clearly distinct can produce the same slug.
For an editorial workflow, save three fields: the original subject, the publishable heading and the slug. That little separation makes corrections easier. You can change a comma in the heading without asking anyone to update a bookmarked URL.
Choose sentence case or title case
Sentence case suits instructional copy and interface labels. How to clean a CSV file before sharing it reads like a sentence and keeps the acronym recognizable. Title case often suits a publication that already capitalizes major words: How to Clean a CSV File Before Sharing It. The decision should come from the style of the surrounding page, not from the idea that capitalized headings rank better. Compare your draft with two existing headings from the same section and check how they handle articles, conjunctions and prepositions.
Paste only the heading and apply a case mode. Then read the result as a sentence, not a string of tokens. If it is a question, preserve the question mark; if it has a subtitle after a colon, check whether the publication capitalizes the first word of that subtitle. Also look at short terms that change role: up is not doing the same job in “walk up the hill” and “set up a workspace.” An automatic converter does not parse those editorial distinctions.
Keep typography consistent within a group of cards or guides. A one-off correction is useful, but setting a consistent rule for the whole section saves more time later.
Check names and acronyms after changing case
General casing rules cannot tell which letters are intentional. Write down items such as iPhone, eBay, GitHub, PDF, and names that include internal capitals or accents. Add a product spelling to the preferred spellings control if you are correcting a batch. For uncommon acronyms, still read the output rather than assuming a built-in list covers your subject. A capitalization tool does not know that US means a country in one heading and is the pronoun us in another.
Watch for adjacent punctuation and variants. iPhone-ready, iPhone’s and iPhones are not identical strings. Treat each form as a separate check. For a multilingual title, use the original native spelling as the reference rather than attempting to reconstruct it by changing case again. Some Unicode characters can expand when uppercased, so lowercasing that result need not recover the input.
For a batch of twelve headings, use a small sample before applying the rule to all twelve. Pick a normal heading, one with a name and one with an acronym or number. If those three are right, run the rest and skim for exceptions; keep the originals for comparison.
Know when to capitalize every word
Capitalize Each Word and Title Case solve different problems. A word-initial style is handy for compact cards or a catalog where every word should start with a capital. A title-case preset deliberately leaves some short words lowercase when they are not at an edge. With a draft such as notes from a shared desk, “Notes From A Shared Desk” and “Notes from a Shared Desk” communicate the same idea but give the group of titles a different rhythm.
A converter cannot implement all style books at once. If you write to a formal guide, check its rules for hyphenated compounds, prepositions and the first word after a colon. Avoid jumping between presets just to make one heading look better. Pick the closest preset, make any exceptions explicitly and use that same starting point for the next article.
Swap Case is different again: it reverses the case of cased characters and is mostly useful for experimenting or spotting inconsistent input. It is not a heading style and not a dependable way to recover an earlier version. In scripts or formulas, take extra care because the letter case may be part of a variable name rather than a typographic choice.
Make one short and readable path segment
Take the heading, remove any subtitle that is not needed to recognize the page and open the slug and identifier converter. Keep kebab-case for a typical web path. Start with the subject and action: “Clean up extra spaces in a spreadsheet: before and after” can become clean-extra-spaces-spreadsheet. A searcher should be able to tell this apart from another guide on extra spaces in copied PDF text. If removing a term makes those links indistinguishable, put it back.
Don't feed the tool an entire URL. A value like https://example.com/guides/a-title/?ref=notes includes a scheme, a domain, path separators and a query parameter. A slug belongs in one segment of the path. Generate the segment, place it in the right directory in your publishing system and confirm the final link there.
Look at apostrophes and symbols in particular. A literal splitter may turn beginner’s into beginner-s; if your convention is to keep the possessive together, use beginners or reword it. If a title is mostly emoji or punctuation, decide on a readable text label yourself. Empty output is a signal to choose words, not a reason to paste in a row of separators.
Choose a policy for accents and other scripts
For Café menus in Québec, you might keep the accented letters in the slug if your site already uses accented URLs, or generate cafe-menus-in-quebec if it uses Latin ASCII for its paths. Look at your publishing platform and the people who will share the link. Some tools display the decoded characters, while others show their percent-encoded representation. A visually long link may therefore still point to a short human-readable path.
The Latin accent option does not translate or transliterate arbitrary writing systems. Do not assume that a slug in Japanese, Greek or Arabic will become an English equivalent. For a localized page, you can choose an approved translation, a project-specific romanization or the original script, as long as your platform supports it. Copy a test link into the place where readers will see it, then open it and verify that it points to the intended language version.
Keep the heading written correctly even when you simplify the path. A page called Résumé templates can have an ASCII path without dropping the accents from its visible title. Likewise, do not strip accents from an author name just because you stripped them from the URL.
Use a different format for identifiers and files
The same words can become invoice_due_date, invoiceDueDate, InvoiceDueDate or INVOICE_DUE_DATE. Use the identifier converter to preview a name in the convention the receiving project expects. Check the neighboring identifiers first. An object key in a JSON export, a class name and a Python variable name are not interchangeable just because they describe the same field.
Always apply the receiving system's naming rules separately. A format converter does not know whether 2026Revenue is allowed, whether a word is reserved or whether the project already has another identifier that differs only by capitalization. Don't paste a batch of renamed API fields into production until you have checked what imports, tests and clients expect. If an external consumer relies on the old names, maintaining compatibility is more important than cosmetic consistency.
For a file, isolate the base name and preserve the real extension. You might change Q4 Sales Notes.PDF to q4-sales-notes.pdf, but avoid feeding in an entire filesystem path or stripping the dot from the extension. On shared storage, look for a name already in use and keep a clear date or version when it carries meaning.
Don't use a slug as a URL-encoded value
A slug is a deliberate rewrite. Percent encoding keeps the original value recoverable by representing certain bytes with a percent sign and hex digits. For a query value such as Café & tea, turning it into cafe-tea loses the accent, the ampersand and the spaces. If a form or integration needs that exact value, use the URL component encoder instead and encode only the value, not the entire link.
For example, a URL builder may take a search field and generate ?q=Caf%C3%A9%20%26%20tea. Here the ampersand inside the value is encoded so that it cannot be confused with a separator between parameters. A form that uses a plus for spaces may generate a different but appropriate representation. Let the system that owns the link handle that convention if it provides a dedicated field.
Don't encode an already encoded component blindly. If a value containing %20 turns into %2520, a single decode now returns the literal string %20, not a space. Work from the original value, encode once for the target context, and verify the link after copying it into the actual page.
Check uniqueness before setting the path
Slugs can collide even when the source titles look different. For example, 2026 Q&A and 2026 Q A may produce the same segment after punctuation is split into separators. Titles with accent differences may collapse to the same ASCII slug if that setting is on. Check existing published pages, drafts and any redirect list in the same route namespace before saving the result. The browser utility only sees the text you paste; it cannot check your site's database or claim a URL.
When you find a collision, use a meaningful distinguishing term rather than tacking on an unexplained suffix. A site with prepare-csv-for-import and prepare-csv-for-markdown is easier to maintain than one with prepare-csv, prepare-csv-2 and no clue about which page does what. For multiple yearly editions, including the year may be helpful if each one is a distinct resource. For an evergreen guide, a year might become misleading.
Confirm what your system does with a trailing slash, capitalization and a duplicate submission. Compare the public page with the link shown in the editor, and save the final URL in your publishing notes.
Preserve established URLs during a title edit
When an existing article gets a clearer title, the slug can usually stay as it is. A link in an old newsletter or a support article should still work. Change the heading, update the page title if appropriate and follow the original link to make sure the publishing system did not silently regenerate the route. Avoid turning a routine text edit into a migration without a reason.
If the URL really must change, treat it as a separate release step. Make a note of the old and new paths, plan a permanent redirect with the person who manages the site and update internal links to the new destination. Verify both URLs: the old one should lead to the right replacement, and the new one should serve the content. Review sitemap and canonical values too. The tool can suggest a path, but it does not modify the site or configure a redirect.
Do not redirect many different articles to an unrelated home page just because their old paths are awkward. If there is an appropriate replacement, point to it directly. For a heading-only edit, none of this should be necessary: the old path should remain reachable as before.
Run a small publishing check
Read the visible heading out loud. Then read just the slug, without seeing the page, and ask what it tells you. Next compare names, acronyms, numbers and accents with your original. A small typo in a brand name is visible to readers even if a case conversion technically did what you selected. If you are editing a series of headings, place them next to one another and look for inconsistent treatment of short words and punctuation.
Try the whole workflow on how to print a PDF from iPhone: three settings to check. Preserve PDF and iPhone in the display title, decide whether a subtitle belongs on the page and use the slug tool on the shortened phrase. A path such as print-pdf-from-iphone expresses the action without promising a particular result. Use the actual title on the page rather than presenting the path as reader-facing text.
Finally, copy the generated public URL and open it independently of the editing session. That checks a different thing from the preview: it confirms that what you plan to share is in fact reachable. Keep the final title and URL together in your notes so the next person can revise the title without guessing which page it belongs to.