Why doesn't title case follow AP or Chicago style rules?
The title transform here is the simple English-oriented rule: capitalize the first letter of every word, lowercase the rest. AP Stylebook and Chicago Manual title case both have additional rules — articles (`a`, `an`, `the`), short prepositions (`of`, `in`, `to`, `for`, `on`), and conjunctions (`and`, `but`, `or`) typically stay lowercase except at the beginning or end of the heading; verbs and pronouns get a capital regardless of length; the two style guides disagree on edge cases like `vs.`, `etc.`, and hyphenated compound words. Implementing every variant is doable, but the output would be wrong-by-default for any user whose destination follows a different style. The mechanical "capitalize every word" rule is honest about what it does and gives editorial users a starting point that still needs a human proofread for short words. For prose drafts, internal docs, and product copy that does not follow a specific stylebook, the simple rule is usually what you want anyway.
Does sentence case handle abbreviations and quoted speech?
No — sentence case capitalizes the first letter after a period, question mark, or exclamation mark, and lowercases the rest. It does not detect abbreviations like `U.S.A.`, `Mr.`, or `e.g.`, so the period after `Mr.` will be treated as a sentence break and the next word will be capitalized whether it should be or not. It also does not detect quoted speech, parenthetical asides, or the rule that a colon's right-hand side stays lowercase except in legal writing. The transform is honest about its mechanical scope: it gives you a starting point for re-casing all-caps body text or messy mixed-case prose, and a careful proofread is still required for anything going to publication.
How do camelCase, PascalCase, snake_case, kebab-case, and CONSTANT_CASE split the input?
Identifier transforms split the input into words at three boundary types: whitespace (any space, tab, or newline), non-alphanumeric punctuation (commas, dots, brackets, slashes, and the rest), and existing case boundaries — both lowercase-to-uppercase (`firstName` splits at `tN`) and digit-to-uppercase (`Field2Name` splits at `2N`). Once split, digits stay attached to the adjacent letter token in either direction; the splitter does **not** introduce a break between letters and digits when both sides are lowercase, so `field2name` stays one token `field2name` rather than splitting silently. The honest split rule: `Field2Name` re-emits as `field2Name` (camel), `Field2Name` (Pascal), `field2_name` (snake), `field2-name` (kebab), or `FIELD2_NAME` (constant); `field2name` survives the round-trip unchanged because nothing in it tells the splitter where the word break should land. Empty tokens from consecutive separators are dropped, so `first name` and `first..name` both produce `firstName` cleanly rather than introducing a stray capital from an empty piece.
Does the tool destroy non-ASCII characters or accented letters?
No. The transform uses the browser's native `String.prototype.toUpperCase()` and `toLowerCase()`, which are Unicode-aware: `é` lowercases to `é` and uppercases to `É`, `ß` uppercases to `SS` (the standard JavaScript engine rule), and CJK characters pass through unchanged. The identifier transforms treat letters with diacritics as letters for word-boundary purposes, so `naïve_user` re-converts to `naïveUser` rather than splitting at the `ï`. Two caveats worth knowing: this tool is not locale-aware — it uses the locale-independent `toUpperCase` and `toLowerCase`, not `toLocaleUpperCase("tr")` / `toLocaleLowerCase("tr")`, so the Turkish dotted-vs-dotless `İ`/`I` distinction follows the JavaScript engine's default rules and the page's `lang` attribute does not change that behaviour; if Turkish-correct casing matters for your input, run the text through a locale-aware library or shell command instead. Second: the German `ẞ` (capital sharp S) round-trip is not stable in current engines, since `ß` uppercases to `SS` and `SS` lowercases back to `ss`, not `ß`.
Why is there no batch upload?
Case conversion runs on text already in your clipboard or in a file open in your editor, not on hundreds of separate files. A single textarea is the right surface: paste, pick a mode, copy the result. If you need to batch-convert filenames or a directory listing, run the transform on the listing as text — `ls -1` output, a printed array, a CSV of filenames — and feed the result back into your shell or rename script. The browser API does not have a privileged file-rename hook to make a batch UI honest, so we do not pretend to offer one.
Will pasted text leave my browser?
No. The transform runs entirely in your browser tab through vanilla JavaScript string operations — no upload step, no fetch to a server, no third-party API call. The input never crosses a network boundary, which matters when the text carries log lines with user emails, partial database dumps, source code under NDA, or internal copy that a mainstream "free online case converter" would happily accept and silently retain on its servers for "performance reasons." The page itself loads from `niftywebtools.dev` once; after that, it is a local string transform with no further network traffic.
Which browsers can run this case converter?
Every current Chrome, Edge, Firefox, and Safari, plus mobile Chrome and Safari. The transform uses only `String.prototype.toUpperCase`, `toLowerCase`, regular expressions, and standard string concatenation — capabilities that have been universally supported since the very early ECMAScript days. There is no canvas, no decoder, no WASM module to fetch, and no MIME defensive check to fail through. The page itself is the only thing that needs JavaScript turned on; with JavaScript disabled the noscript fallback explains why and links to the privacy page.
Will this tool stay free?
The basic workflow is designed to stay free. Paid upgrades later will focus on bigger limits, batch work, OCR, saved presets, and ad-free use.
JSON Formatter
PDF to Text
Convert Image Files