Text to dot.case converter

What dot.case is and where it appears

dot.case writes a multi-word name in all lowercase and joins the words with periods: user.profile.image, app.feature.dark-mode, errors.validation.required. The dot is doing real structural work in most of its uses, since it usually represents nesting or namespacing rather than just a word boundary. That makes dot.case feel a little different from snake_case or kebab-case: it often encodes a hierarchy, where each dot steps one level deeper into a tree of settings or keys.

You meet dot.case most often in configuration and tooling. Properties files in the Java world use dotted keys like spring.datasource.url. Internationalization libraries key their translations with dotted paths such as checkout.payment.cardNumber. Feature-flag systems, logging namespaces, metrics names in tools like StatsD and Graphite, and many CLI config formats all use dotted keys to express grouping. Some package and module systems use dots as namespace separators too.

How the converter produces dot.case

The conversion is the familiar two-step process. First the input is split into words at spaces, existing underscores or hyphens, dots, and the capital letters inside a camelCase or PascalCase identifier. Second, every word is lowercased and the words are joined with a single dot. So "User Profile Image" becomes user.profile.image, "darkModeEnabled" becomes dark.mode.enabled, and "max-retry-count" becomes max.retry.count.

Because dots frequently mean nesting, think about whether your input already implies a hierarchy. If you paste "checkout payment card number", you get checkout.payment.card.number, a four-level key, which may be exactly right or may be one level too deep for your config schema. The converter treats every word as its own segment; if you want "card number" to stay together as cardNumber inside the key, convert that part to camelCase first and then build the dotted path around it.

Leading and trailing whitespace is trimmed and runs of separators collapse to a single dot, so you never get an empty segment. As always, glance at the output for acronyms and numbers before using it as a real key, since a translation or config key is something many other lines of code will reference by exact string.

When a dot.case converter helps

The clearest use is building configuration and translation keys. When you add a new screen to an app, you often need a batch of i18n keys like settings.profile.title and settings.profile.save; converting the human labels into dotted keys keeps the naming consistent with the rest of the file. The same goes for feature flags and application settings, where a tidy dotted namespace makes the config readable and groupable.

Observability tooling is another driver. Metric and log names in many systems are dotted, so turning a human description like "checkout payment success" into checkout.payment.success gives you a clean, hierarchical metric name that dashboards can group by prefix. DevOps engineers wiring up monitoring frequently need exactly this transformation, and doing it consistently across a service keeps related metrics neatly grouped under a shared prefix rather than scattered under slightly different names.

Java and Spring developers reach for dotted keys constantly, because application.properties and YAML configuration both use them: server.port, spring.datasource.url, logging.level.root. When you add a new configurable feature, you usually need a small batch of these keys at once, and converting the human-readable setting names into a consistent dotted namespace is faster and tidier than typing each one by hand and hoping the segments line up.

Paste your words into the live converter above to get the dot.case form immediately. The side panel shows snake_case and kebab-case next to it, so if your config actually expects underscores or hyphens instead of dots you can copy the right variant without starting over.