How does a dotted key like a.b.c = 1 become nested YAML?

Each dot in a key is treated as a nesting boundary, the same convention HOCON itself uses: a.b.c = 1 builds a mapping a containing b containing c: 1. Keys sharing a prefix (a.b.c and a.b.d) are merged into the same nested mapping rather than overwriting each other.

Does this support both : and = as separators, and the key { ... } shorthand?

Yes to all three. HOCON allows : and = interchangeably before a value, and this tool recognizes both, plus the shorthand key { ... }, meaning key = { ... }, for defining a nested object without an explicit separator.

What happens with ${substitution} references and include directives?

Both are out of scope for evaluation. A ${...} substitution (optionally with trailing text, like ${HOME}/bin) is kept as a literal string rather than resolved against other keys or environment variables. An include directive is reported as an explicit, named error rather than silently ignored or misparsed.

Is HOCON's object-merging-by-repetition behavior implemented?

Not fully. This tool does merge dot-path segments that share a common prefix (necessary for a.b = 1 and a.c = 2 to coexist under a), but it doesn't implement HOCON's full specification for how repeating an entire object key later in a document merges with (rather than replaces) the earlier one.

Does this tool send my HOCON config anywhere?

No, parsing and YAML generation both happen entirely client-side with a small hand-written parser. Nothing you paste is uploaded.

HOCON to YAML Converter - Convert Typesafe Config Online

Overview

Introduction

HOCON, best known as the config format behind Typesafe/Lightbend's Config library and widely used in Scala and Akka projects (application.conf), is a JSON superset with convenient shorthand like dotted keys and optional separators. This tool parses a practical subset of it and re-expresses it as YAML.

It's a hand-written recursive-descent parser covering the features most real HOCON config uses: key/value pairs, dot-path expansion, nested objects, and arrays, while explicitly declining to implement HOCON's substitution and include machinery.

What Is HOCON to YAML?

A HOCON-to-YAML converter tokenizes HOCON source (bare and dotted identifiers, quoted strings, numbers, booleans, null, and punctuation) and parses it as a sequence of key/value pairs, either at the document root or nested inside { } objects.

Each key's dot-separated path is expanded into nested objects as it's assigned, and the resulting object tree is serialized as YAML using the same stringifier every other tool in this category uses.

How HOCON to YAML Works

Each key/value pair is either key: value, key = value, or the shorthand key { ... } (equivalent to key = { ... }). The key portion is split on ".", and that path is walked into the target object, creating intermediate objects as needed, matching HOCON's own rule that a.b.c = 1 is shorthand for a: { b: { c: 1 } }.

Values are strings, numbers, booleans, null, nested { } objects, or [ ] arrays (comma-separated, with commas between object entries and array elements both optional, matching HOCON's own relaxed syntax). # and // both start a line comment, stripped during tokenizing.

When To Use HOCON to YAML

Use it when migrating a Scala/Akka application.conf, or any other HOCON-based config, into a YAML-based deployment pipeline.

It's also useful for previewing how HOCON's dotted-key shorthand expands into actual nested structure, before committing to a full migration.

Often used alongside HCL to YAML, Properties to YAML Converter and YAML Formatter & Prettifier.

Features

Advantages

Correctly expands dot-separated keys into real nested YAML mappings, including merging multiple dotted keys that share a common prefix.
Supports both : and = separators and the key { ... } block shorthand, matching HOCON's actual flexibility.
Reports include directives as an explicit, named error instead of a confusing generic syntax error.
Runs entirely client-side with no added dependency, so configuration values never leave your browser.

Limitations

${substitution} references are not evaluated; they're kept as a literal string, so the output won't reflect what the substitution would actually resolve to.
include directives are explicitly unsupported and reported as an error rather than being fetched or inlined.
HOCON's full object-merge-by-repetition semantics (a later full re-declaration of an object key deep-merging with an earlier one) aren't implemented beyond the basic prefix-sharing needed for dotted keys to work at all.

Examples

Dot-path expansion

Input

a.b.c = 1
name: "api"

Output

a:
  b:
    c: 1
name: api

The dotted key a.b.c expands into nested mappings; both ":" and "=" separators are accepted.

The key { ... } object shorthand

Input

nested {
  x = 1
}

Output

nested:
  x: 1

No separator is needed before a { ... } block, matching HOCON's own shorthand.

Best Practices & Notes

Best Practices

Expect ${...} substitutions to appear unresolved in the output, treat them as a marker for where a real value needs to be filled in, not a bug.
Avoid include directives in input you plan to convert with this tool, split multi-file HOCON config into one file first.
Run the result through the YAML Formatter afterward if you want to double-check indentation consistency.

Developer Notes

The tokenizer treats ${...} as a special case, scanning a balanced (single-level) brace pair plus any immediately-adjacent bare text and emitting it as one literal string token, so substitutions like ${HOME}/bin pass through as text without the parser trying to interpret the $ or braces as syntax. Dot-path assignment shallow-merges when both the existing and new values at a path are plain objects, which is what makes multiple dotted keys under a shared prefix combine instead of clobbering each other.

HOCON to YAML Use Cases

Migrating a Scala/Akka application.conf into a YAML-based deployment pipeline
Converting Lightbend Config-based application settings into YAML for a framework that expects it
Previewing how a HOCON file's dotted keys and nested blocks expand into an object tree
Generating YAML fixtures for tests from an existing HOCON source file

Common Mistakes

Expecting ${some.reference} to resolve to another key's value, it doesn't, it's kept as a literal string.
Using an include directive and expecting the referenced file's contents to be inlined, it isn't, this tool reports it as an unsupported feature instead.
Assuming every possible HOCON object-merge edge case (deep merging two full re-declarations of the same object key) behaves identically to Lightbend's reference implementation, this tool only guarantees dot-path prefix merging.

Tips

If your HOCON config uses include, inline the referenced file's content manually before converting.
Use YAML Sorter afterward if you want the converted mapping's keys in alphabetical order rather than source-file order.
For config with many dotted keys, converting to YAML often makes the resulting nesting easier to read at a glance than HOCON's flat dotted-path style.

HOCON to YAML