Data and structured data
What happens to null and dates when converting JSON to TOML?
Tools to use
Changing a configuration format means more than changing an extension. The string true and boolean true differ, as do null and an empty value, or a date-looking string and a date value. Round-trip a small configuration through JSON/TOML and check the receiving application's expected types.
Start with a small baseline
{"name":"demo","enabled":true,"retries":3,"ports":[8000,8001]}Convert this input and check name as a string, enabled as a boolean, retries as a number and ports as an array. Feed the result back to obtain JSON. Whitespace or key presentation may differ, but types and values should not. Write down demo, 3 and ports 8000/8001 as independent expectations before inspecting the output.
Direction is inferred from the first character: { or [ selects JSON. A TOML document starting with a table header therefore conflicts with that heuristic. These examples begin with a key/value line. Treat such detection failures as a tool limitation, not a successful conversion.
Decide what null means before replacing it
{"name":"demo","timeout":null}Conversion rejects this because TOML has no null value. Do not substitute 0 or an empty string just to suppress the error: zero may mean no wait, unlimited wait or invalid input, while omission may select a default. The converter cannot decide the application's intended semantics.
Document semantic edits explicitly, such as omitting timeout:null to use the receiver's default. Removing null from an array shifts later positions, so an apparently similar deletion can have a different effect from removing an object property. Preserve that distinction during review.
Round-trip a date string and a date value
name = "demo"
created = 2026-01-02T03:04:05Z
label = "2026-01-02T03:04:05Z"Dates are rejected by default. Enable the explicit TOML-date-to-string mapping before trying this example. created is written as a TOML datetime; label is a string. JSON output can make both look like date strings. Converting back does not necessarily restore created's original TOML type. Similar spelling is not evidence that the original type survived; check what type the consuming application receives.
Normalization may change fractional-second or offset spelling. Even if the instant is unchanged, exact text can matter for logs or signatures. Distinguish a local date, an offset-bearing instant and a display label; decide which fields must remain strings instead of inferring missing time-zone information.
Review comments separately from runtime values
retries = 3 # temporary limit for the test environment
name = "demo"The comment is not carried as a JSON value. retries can remain 3 while the operational reason for choosing 3 is lost. That is not a numeric change, but it matters for maintenance. Decide whether important rationale belongs in documentation or alongside the original configuration.
Whitespace and key order may change too. Separate presentation diffs from value diffs, using JSON structural comparison where appropriate. That comparison still does not preserve comments or prove TOML-specific type equivalence. Combine several narrowly defined checks rather than treating one as universal validation.
Large integers test the converter as well as the format
{"id":9007199254740993}A number preserved by JSON Formatter is not automatically supported by this TOML conversion. This input exceeds the exact JSON-to-TOML range and is rejected. A format's integer range and an implementation's conversion range differ. Do not round an ID to bypass the error; check whether the data contract permits a string.
Build a checklist for numbers, booleans, arrays, nulls, dates and comments. One passing example is not migration completion: test each type actually present. A converter limitation is not permission to change the configuration contract. If required information cannot survive, reconsider the conversion method or format.