JSON to Swift

Why generate Swift structs from a sample?

Codable's synthesis is wonderful until a key goes missing: then a decode that worked on every sample you tried throws in production, because the property you declared non-optional was absent from the response you never saw. Swift model code is a set of claims — this key always exists, it is always a string, its name is camelCase — and the sample is the only evidence available for those claims before the app ships. This converter reads the sample the way a careful reviewer would: objects become Codable structs, arrays become [T], absence and null become Optionals, renames produce a complete CodingKeys enum that pins every wire name, and the slots no sample could settle become a small JSONValue enum that is appended, explained, and ready to compile — not an Any that Swift would reject.

How to use this tool

1. Paste the JSON. A real API response is ideal; include several array elements if you have them, because absence across elements is how Optional properties are discovered.
2. Name the root struct. Root is fine for a quick look; for code you will keep, use the name it will wear in your project.
3. Press Generate Swift. The root struct comes first, the structs it references after it, and the JSONValue helper last if it is needed.
4. Read the notes if any appear. They list every JSONValue slot, every backticked keyword property and every name collision — nothing was decided silently.
5. Copy or download the result, then refine it: adjust CodingKeys where your API's naming has rules a sample cannot show, swap in Date or URL where strings are really those, and let the compiler take it from there.

The rules it follows

Numbers. Whole numbers become Int; any fraction widens the slot to Double — a JSON 1.0 is the number 1 to every parser, so a field your API always sends as 2.0 reads as an integer sample unless a real fraction appears. Names. Structs are PascalCase after the key that holds them; properties are camelCase. When a property's spelling differs from its key, the struct gains a CodingKeys enum listing every property — renamed ones with their raw value, others bare — because a partial enum is a trap. Absence and null. Missing from some elements or sometimes null → Optional. Null everywhere or genuinely mixed types → JSONValue, with the helper enum appended and the slot noted. Merging. Identical shapes — same keys, same types — share one struct instead of being emitted twice.

Worked example

Given this sample (the second user has no nickname, and the keys are already camelCase):

{
  "teamName": "Platform",
  "users": [
    { "id": 1, "firstName": "Ada", "nickname": "ada" },
    { "id": 2, "firstName": "Grace" }
  ]
}

the converter emits — no CodingKeys are needed, because no name had to change:

struct Root: Codable {
    let teamName: String
    let users: [User]
}

struct User: Codable {
    let id: Int
    let firstName: String
    let nickname: String?
}

The String? is the second user talking: a non-optional nickname would make JSONDecoder throw on exactly that response. Had the sample spelled that key first_name, User would also carry a CodingKeys enum listing all three properties, with case firstName = "first_name" pinning the wire name.