Hyphens vs. Underscores in URLs: Which Should You Use?

· 2 min read

Use hyphens. That has been Google's explicit, documented recommendation for well over a decade, and nothing about it has changed. But the why is worth understanding, because it explains several other slug rules too.

How search engines tokenize URLs

When a crawler processes blue-widget-review, it splits the string on hyphens and indexes three tokens: blue, widget, review. The page can now match queries containing any of those words.

Underscores historically worked differently. blue_widget_review was treated as a single token — blue_widget_review — matching almost nothing, because the underscore convention came from programming, where my_variable_name genuinely is one identifier. Search engines adopted that interpretation and, per Google's own statements, largely kept it.

The practical result:

/blue-widget-review   → tokens: blue, widget, review  ✓
/blue_widget_review   → token:  blue_widget_review    ✗
/bluewidgetreview     → token:  bluewidgetreview      ✗

Does it still matter in 2026?

Modern ranking systems are far better at reading mashed-together text than they were when this guidance first appeared, and a page won't tank because of underscores alone. But three practical arguments still favor hyphens:

  1. Google's documentation still says so. The official URL structure guidelines recommend hyphens and explicitly advise against underscores. When the search engine tells you its preference, take it.
  2. Readability for humans. Underscores disappear under the link underline in most browsers and documents — blue_widget renders as what looks like blue widget with invisible glue. Hyphens stay visible everywhere.
  3. Consistency costs nothing. There is no counter-benefit to underscores in public URLs. When one option has advantages and the other has none, the decision makes itself.

The case where underscores are fine

Internal identifiers that never compete in search — API endpoints, query parameter names, machine-to-machine URLs — can use whatever your codebase prefers. api.example.com/v2/user_profiles?sort_by=created_at is idiomatic and harmless, because no one is ranking API routes for keywords. The hyphen rule applies to URLs that appear in search results and get shared by people.

What about camelCase and other schemes?

blueWidgetReview combines the tokenization problem of underscores with a case-sensitivity trap: someone will eventually type it lowercase, and URLs are case-sensitive after the domain. Every scheme other than lowercase-with-hyphens fails on at least one of tokenization, readability, or case safety. That's why kebab-case won.

Converting existing content

If your site already uses underscores, don't panic-migrate. Changing established URLs means 301 redirects, and a redirect has a real (if small) cost, while the underscore penalty is minor. The sensible policy: new pages get hyphens, old pages keep their URLs until you have another reason to move them — and when you do slugify new titles, a slug generator that defaults to kebab-case makes the right choice automatic. If your platform genuinely requires snake_case, the same tool supports it as an explicit option.