Online Data Converters for Developers
Convert dates, cron schedules, JSON, YAML, TOML, loose pseudo-JSON, tables, and numeric bases with local browser tools.
Choose a tool
A conversion preserves meaning only when the types and the time zone survive it.
Six tools bridge formats that do not share the same rules about types, ordering, or time. Two of them are about time, three are about moving a document between shapes, and one is about how a number is written down. In every case the output can look completely correct in a preview and still be misread by the system that loads it next, because the formats disagree about what a bare value means.
Getting into JSON, then out of it
Loose JSON Converter is the front door when what you are holding is not JSON at all: a Java map or a Lombok toString dumped into a log, with unquoted keys and equals signs instead of colons. Run that first, because nothing downstream will accept it.
Once the document really is JSON, the destination decides the tool. JSON to Table Converter flattens it into rows you can read and export as CSV, which is right for inspection and for handing data to a spreadsheet. JSON to YAML & TOML Converter keeps the nesting and moves the document into a configuration format instead.
The two are not substitutes. A table forces a decision about nested objects and arrays, and that decision loses information. YAML and TOML keep the structure but impose their own type rules, which is where an unquoted yes becomes a boolean.
Time: Date & Timestamp Converter and Cron Expression Parser
Date & Timestamp Converter handles Unix timestamps, time zones, and relative dates. The ambiguity that costs the most time is seconds against milliseconds, because both look like a plausible integer and a wrong guess lands you in 1970 or in the year 55000. The second is the time zone: a converted value without its zone recorded beside it is not a fact.
Cron Expression Parser validates syntax and predicts upcoming runs. Cron is not one language: five fields is the classic form, six adds seconds, and Quartz adds day-of-week semantics of its own. Preview in the dialect and the zone your scheduler actually uses, and remember that daylight-saving transitions can skip or duplicate a run.
Number Base & Radix Converter, and what a preview does not prove
Number Base & Radix Converter moves a value between binary, octal, decimal, and hexadecimal, and also handles RFC 4648 encodings and custom alphabets. Keep the two ideas apart: writing the same number in another base is not the same as encoding a byte sequence.
Every tool here produces something that looks right on screen. Load the result with the real consumer before it becomes operational data: the YAML loader your service uses, the scheduler that owns the cron entry, the importer that will read the CSV.
Before you rely on a result
- State whether a timestamp is in seconds or milliseconds, and record the time zone next to every converted value.
- Run pseudo-JSON through the Loose JSON Converter first. A structure with unquoted keys and equals signs is not JSON and nothing downstream will parse it.
- Check quoting after converting to YAML. Unquoted yes, no, on, and off are booleans there, and a leading zero can change a number's base.
- Decide what happens to nested objects and arrays before exporting JSON to CSV, because flattening is lossy by nature.
- Preview cron in the scheduler's own dialect and time zone, and check the behaviour across a daylight-saving transition.
Frequently asked questions
My timestamp converted to a date in 1970. What happened?
A millisecond value was read as seconds, or the reverse. A ten-digit integer is almost always seconds and a thirteen-digit one almost always milliseconds, at least for dates near the present. Set the unit explicitly rather than letting a tool infer it from length.
Why does my YAML behave differently from the JSON it came from?
YAML infers types from unquoted text. Words like yes and no become booleans, a value with a leading zero may be read as octal, and a version string such as 1.10 becomes a number that loses its trailing zero. Quote anything that is meant to stay a string.
Will my cron preview match what the scheduler does?
Only if the dialect and the time zone match. Five-field cron, six-field cron with seconds, and Quartz differ in real ways, and a scheduler running in UTC will not agree with a preview in local time. Confirm both against the system that owns the job.
Browse all developer tools or read the developer tool guides for worked examples.