Use the free JSON to Swift Codable below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
JSON to Swift Codable Structs Without the Busywork
iOS developers know this task well. An API returns JSON, and Swift wants a struct that conforms to Codable, with properties of the right types and CodingKeys wherever the JSON names differ from Swift style. Writing that by hand for a large response is slow, and it is easy to mistype a key or choose the wrong type. This tool generates the structs from your JSON, including CodingKeys when they are needed, so you can focus on what your app does with the data.
Paste the JSON, set the root struct name, and press Convert. The output is a set of structs, each conforming to Codable. Text becomes String, whole numbers become Int, decimals become Double, true and false become Bool, and arrays become Swift arrays of the element type. Properties use let, which suits the value-type style Swift developers usually want.
CodingKeys, Handled for You
Swift convention uses camelCase for property names, and JSON often uses something else. A key like user_name becomes userName in the generated struct, and because that differs from the original key, the tool adds a CodingKeys enum mapping userName back to user_name. Without that mapping, decoding would fail or silently leave the property empty, depending on your decoder settings. With it, decoding just works.
When the JSON key already matches the Swift property name, no CodingKeys entry is needed, and the tool leaves it out. That keeps the output short and readable. If your project uses a key decoding strategy instead, such as converting from snake_case automatically, you can delete the CodingKeys enums and set the strategy on your JSONDecoder. The generated code works either way: it is explicit by default, and easy to simplify if your decoder already handles the naming.
Types, Arrays, and Nulls
The type rules are straightforward. Whole numbers become Int, decimals become Double, strings stay strings, and booleans become Bool. Arrays become Swift array types: an array of strings becomes an array of String, and an array of objects becomes an array of a new struct, named by singularizing the field name, so orders produces an Order struct.
Null values are the honest edge case. A field whose sample is null becomes an optional String, with a note at the top of the output telling you to change it to the real type. That default is a placeholder, not a claim about your data. Replace it with the actual type, such as Int or a custom struct, once you know what the field holds. Empty arrays get the same treatment: they default to an array of String, and you replace the element type with the real one.
Optional fields deserve a decision too. If a field is sometimes missing from the response, declare it optional in your struct so decoding does not fail when it is absent. The tool generates non-optional properties from the sample, because the sample shows the field present. After generation, mark the properties that your API documentation says are optional. That one pass over the output prevents a whole class of decoding crashes.
Nested Structs and Naming
Nested objects become their own structs. An address object becomes an Address struct. An array of orders becomes an array of Order. The structure of the generated code mirrors the structure of the JSON, which makes it easy to navigate: the root struct points to the nested structs, and each nested struct holds its own fields. If two fields would produce the same struct name, the tool numbers the second one so the code compiles, and you rename it to something meaningful afterward.
Name the root struct well before you convert. A name like UserProfile or ApiResponse tells the next developer what the struct is. A name like Root tells them nothing. The same applies to nested structs: if the tool numbers one, that number is a prompt to choose a better name, not a final answer.
Testing the Generated Models
Test with real responses, not just the sample you converted. Decode the fullest response you have, then decode a second, different response from the same endpoint. Look for three problems: fields that change type between responses, fields that vanish, and arrays that are empty in one response and full in another. Each problem has a small fix: a wider type, an optional property, or a corrected element type.
Be careful with numbers. A timestamp in milliseconds can exceed the range of a 32-bit integer, though Swift Int is 64-bit on modern devices, so this is less of a trap than in some languages. Decimals that sometimes arrive as whole numbers are still worth checking: a Double property handles both forms, while an Int property fails on the decimal form. When a field can be either, choose Double.
Also check stringly typed data. APIs often send dates as strings. A date sent as “2026-10-27” is a String in the generated struct, which is correct as a starting point. If you want a Date property, add a date decoding strategy to your decoder or write a custom initializer.
Privacy
Everything runs in your browser. Your JSON never leaves your device, is never stored, and is never sent to any server. You can convert responses containing real user data safely, though as always, keep access tokens and passwords out of pasted text. The tool is free and needs no account.