TOML Inline Tables and JSON Objects
Learn how TOML inline tables provide compact object syntax similar to JSON. Understand when to use inline tables vs standard tables and how they convert to JSON.
Detailed Explanation
Inline tables in TOML provide a compact, single-line syntax for defining objects. They look very similar to JSON objects and are ideal for small, simple data structures.
TOML inline tables:
point = {x = 1, y = 2}
name = {first = "Tom", last = "Preston-Werner"}
Converts to JSON:
{
"point": {"x": 1, "y": 2},
"name": {"first": "Tom", "last": "Preston-Werner"}
}
The conversion is straightforward since inline tables closely mirror JSON's object syntax.
Inline tables vs standard tables:
The same data can be written two ways in TOML:
# Standard table
[address]
street = "123 Main St"
city = "Springfield"
state = "IL"
# Inline table (equivalent)
address = {street = "123 Main St", city = "Springfield", state = "IL"}
Both produce identical JSON:
{
"address": {
"street": "123 Main St",
"city": "Springfield",
"state": "IL"
}
}
Key restrictions of inline tables:
- Must be on a single line. Inline tables cannot span multiple lines (as of TOML v1.0). This limits their practical use to small objects.
- Cannot be extended. Once defined, you cannot add more keys to an inline table elsewhere in the file. Standard tables allow keys to be added in sequence.
- No nested table headers. You cannot use
[table]header syntax inside an inline table.
When to use inline tables:
- Small objects with 2-3 simple key-value pairs
- Array elements that are objects:
items = [{id = 1, name = "a"}, {id = 2, name = "b"}] - Configuration values that are conceptually a single unit (e.g., coordinates, dimensions)
When to prefer standard tables:
- Objects with more than 3-4 keys
- Objects containing nested objects
- Any structure that benefits from multi-line readability
When converting JSON to TOML, a good converter decides between inline and standard table syntax based on the complexity of each object.
Use Case
Defining compact metadata or small configuration objects in TOML files where a full table header would add unnecessary verbosity, such as specifying coordinate pairs, version constraints, or simple key-value maps.