Every naming convention at once, from one paste. Useful when you are moving a field list between a database, a JSON API and a TypeScript model and each layer insists on a different style.
Renaming an identifier across languages means moving between conventions that are not interchangeable: camelCase for JavaScript variables, PascalCase for classes and components, snake_case for Python and SQL columns, kebab-case for URLs and CSS, CONSTANT_CASE for environment variables.
The conversion here splits on case boundaries as well as on separators, so HTTPResponse and http_response both come apart correctly instead of collapsing into one word — the acronym case is where naive converters fail. The line utilities alongside it — sorting, deduplicating, trimming, numbering, reversing — cover the small text jobs that would otherwise be a throwaway script.
Two conventions collide often enough to be worth naming. HTTP header names are conventionally Train-Case — Content-Type, X-Request-Id — while the same values in most languages appear as snake_case or camelCase, and an acronym in the middle is where converters disagree with each other: XMLHttpRequest, XmlHttpRequest and XML_HTTP_REQUEST are all defensible readings of the same name. Splitting on case boundaries as well as separators is what makes HTTPResponse come apart into HTTP and Response rather than collapsing into one undifferentiated word.
The line utilities cover the jobs that otherwise become a throwaway script. Deduplicating a list while keeping its order, sorting case-insensitively, trimming trailing whitespace that a paste brought along, numbering lines for a reference, reversing an order — each of these takes a minute in an editor and a second here, and none of them is worth opening a terminal for. Doing them in the page also means the text never leaves it, which matters when the list is customer names or internal hostnames.
Case conversion is not always reversible, and knowing where it stops helps. Going from camelCase to snake_case and back returns the original; going from a sentence with punctuation to any programming convention does not, because the punctuation is discarded rather than encoded. Non-ASCII text is another boundary: Korean, Japanese and Chinese have no case at all, so a mixed string keeps its non-Latin characters untouched while the Latin ones change, which is the behaviour you want and the reason the result may look only half converted.
Case conversion is locale-sensitive in one notorious place. Turkish has a dotless i and a dotted one, so the uppercase of i is I in most languages and the dotted capital in Turkish, while the lowercase of I is the dotless one. Code that upper-cases a string to compare it — a filename, a header name, a language tag — produces the wrong answer on a Turkish system, and the bug appears only for users with that locale. This page converts with the invariant rules rather than the browser locale, which is what makes the output the same everywhere and safe to use for identifiers.
Yes. Word splitting uses Unicode letter and number classes, so Korean, Japanese and accented Latin text is preserved rather than stripped. Case changes only affect scripts that have upper and lower forms.
They are nearly the same, but url-slug also strips leading and trailing separators, which is what you want for a URL path segment generated from a title.
No. Every conversion runs in JavaScript in your browser. Nothing is sent to a server and nothing is stored.