Case Converter & Slug Generator

Splitting a name into words and gluing it back together sounds trivial. Then you hit parseHTTPResponse, and suddenly your converter is emitting parse_h_t_t_p_response and nobody knows why.

helloWorld       lower to upper
HTTPResponse     the last capital of a run belongs to the next word
utf8Text         a capital after a digit
hello_world      any punctuation at all
naive cafe       accented letters are letters
café             e plus a combining accent stays one word

The acronym problem

parseHTTPResponse

  runs of capitals kept   parse | HTTP | Response       3 words
  every capital splits    parse | H | T | T | P | ...   6 words

So:
  parseHttpResponse   keeping the run together
  parseHTTPResponse   what the input already was
  parse_h_t_t_p_...   what a naive splitter produces

A run of capitals counts as one word, and the last capital in that run belongs to the word after it. In HTTPResponse theR starts "Response", it is not part of the acronym. Get that backwards and parseHTTPResponse comes out asparse_h_t_t_p_response. You have almost certainly seen that output somewhere.

Splitting it correctly still leaves a choice, and this one is style, not correctness. Google's style guides say treat an acronym like any other word, so you get parseHttpResponse and XmlHttpRequest. Microsoft's say keep two-letter acronyms capitalised and lowercase everything longer. The switch above does both. Neither is wrong.

Where each one belongs

camelCase              JavaScript, Java, JSON keys
PascalCase             types and classes
snake_case             Python, Ruby, SQL columns
SCREAMING_SNAKE_CASE   constants, environment variables
kebab-case             URLs, CSS classes, npm packages
Train-Case             HTTP header names
dot.case               Java packages, config keys

Two of these are real constraints and not just taste. Environment variables are screaming snake because shells are case-sensitive, and the convention is what stops one of yours shadowing a command. HTTP header names are the other one: the spec says they are case-insensitive, but HTTP/2 and HTTP/3 insist on lowercase over the wire. So you write Content-Type andcontent-type is what actually goes out.

Title case is a style guide, not an algorithm

There is no single correct answer here. Chicago lowercases articles, coordinating conjunctions and any preposition under five letters. AP capitalises prepositions of four letters or more. APA capitalises anything of four letters or more, full stop. They disagree about with,from and over, and about plenty else besides.

All three do agree that the first and last words get capitals whatever they are. Both versions sit above: one keeps a small-word list, the other capitalises everything, so pick whichever your style guide asks for.

A line typed entirely in capitals is read as shouting, not as a string of acronyms. That way sentence case of a shouted line actually does something.

Slugs, and what has to come out

A URL slug wants to be lowercase, ASCII, and split on hyphens. Google has been saying hyphens over underscores for years now. Their reasoning is that a hyphen separates words and an underscore glues them together.

Getting accented text down to ASCII works by decomposing it and throwing away the combining marks. é becomes e, ñbecomes n. It works because those characters genuinely are a letter with a mark sitting on top of it.

Plenty of characters are not. ß does not decompose tos. ø is not an o wearing a stroke, andł is not an l. Those get spelled out from a table, along with the symbols people expect to survive the trip:& turns into "and", € into "eur",% into "percent".

For anything outside Latin script it does nothing at all. There is no sensible ASCII for a Chinese or Arabic title, and transliterating would mean guessing at pronunciation, which this tool has no business doing. Those characters are dropped. That is at least honest, and it is why you can turn the option off.

Cutting a slug to length

Chop at a hard character limit and you cut mid-word, so the result reads like a typo. The limit above backs up to the last separator instead. It only gives up on that if backing up would cost more than half the length you asked for.

Search engines have no slug length limit worth designing around. What does matter: keep the whole URL under roughly 2,000 characters, and never change a slug once it is published. A changed slug is a new page plus a 404 where the old one used to be.