The JSON to Rust Struct Converter turns one strict JSON sample into a reviewable Rust draft with Serde derives, but the output is a checklist of inferred decisions, never a finished API contract. Strings become owned String, Booleans become bool, safe JSON integers become i64, and other JSON numbers become f64; null alone becomes Option<serde_json::Value>, null alongside an observed type becomes Option of that type, and nested objects become named nested structs. Because the tool can only see the data you paste, it cannot prove which fields are always present, what numeric width production traffic will reach, or whether a string is really a UUID, URL, date, or enum label. Treat the output as a list of questions your real schema must answer, and use it to spot the places where the contract needs to be written by hand. The generator emits source text in your browser, never uploads the sample, and never installs Cargo dependencies — the mistakes to avoid live in the type choices themselves, not in the surrounding toolchain.
What the generator actually decides for you
The biggest mistake is treating inference output as a finished contract. A single JSON sample can tell you the shape of one payload, but it cannot tell you what other payloads look like — a field present here may be missing in a different response, an integer that fits in i64 in your sample may exceed 9.2 quintillion in another tenant, and a string that looks like "active" may really be a closed enum whose other variants never appeared in the sample. The converter reflects exactly what it sees, so the safer habit is to read the generated source as a list of questions your real schema must answer.
What the generator sees is also bounded by input limits: 500,000 input characters, 50,000 values, 40 nesting levels, and 1,000,000 output characters. Past those limits the inference cannot complete, and treating the output as authoritative becomes even more dangerous. Strict JSON is required too — comments, trailing commas, NaN, Infinity, BigInt syntax, undefined, and JavaScript object literals are rejected, so a non-strict sample will fail before inference even starts. If you want a clean review pass, validate the JSON first with a local JSON syntax checker and fix any flagged issues before pasting.
Numeric widths, Option handling, and mixed-type fallbacks
The type decisions the generator makes are deterministic and worth memorizing, because every one of them is also the place a mistake can hide. The table below summarizes the inference rules the converter applies to each JSON observation; every row corresponds to a row in the source you will paste, so reading the generated code alongside this table is the fastest way to catch errors before compilation.
| JSON observation | Inferred Rust type |
|---|---|
| String value | String |
| Boolean true / false | bool |
| Safe JSON integer (finite, no decimal) | i64 |
| Decimal, exponent, or unsafe integer literal | f64 |
| null alone (no observed sibling type) | Option<serde_json::Value> |
| null combined with an observed type T | Option<T> |
| Array with elements of type T | Vec<T> |
| Empty array [] | Vec<serde_json::Value> |
| Nested object | Named struct with Serialize, Deserialize, Debug |
| Incompatible mixed values in the same position | serde_json::Value (fallback) |
The most common mistake in this column is panicking when a field becomes serde_json::Value instead of a concrete type. The fallback is intentional: when one position in your sample holds a number and another position holds a string, the converter refuses to invent an enum or silently choose the first type. Value preserves the uncertainty until you, the human, decide whether the real contract is a tagged enum, a string, or something else. Similarly, when a JSON key is absent in at least one object inside an array, the missing field becomes Option rather than being marked required — absence in a sample is treated as a real signal of optionality, and production traffic may require even more permissive types.
Numbers deserve special attention because JavaScript parses the JSON before inference runs. That means unsafe integer spellings (anything past Number.MAX_SAFE_INTEGER, about 9.007 × 10¹⁵) cannot be represented exactly and are routed to f64 instead of i64. If your wire contract carries identifiers, currency, timestamps, or any precision-sensitive decimal, keep them as strings in the source contract so the generator does not quietly downgrade them to floating point. The Serde derive documentation describes the supported container and option attributes you can layer on top of the inferred struct once you have committed to the real contract.
Generate, review, and copy a Rust struct from JSON
- Paste a representative strict JSON sample into the JSON to Rust Struct Converter and enter an ASCII root type name such as Root or OrderPayload.
- Generate the source and inspect every decision the generator made — numeric widths, Option wrappers, mixed-type fallbacks, nested struct names, and any serde rename attributes on fields whose Rust name differs from the wire key.
- Confirm that strict JSON was used; if the page rejected the input, fix comments, trailing commas, NaN, Infinity, or non-JSON literals and try again.
- Copy the generated source and paste it into a Serde-enabled Rust project whose Cargo.toml pins a compatible serde and serde_json version — the generator emits text only and adds neither crate.
- Format the file with rustfmt or your editor's formatter so indentation matches the rest of the crate.
- Compile the crate, then round-trip at least three real fixtures (one happy path and two edge cases) through serde_json::from_str and serde_json::to_string before adopting the struct in production code.
Identifier normalization and serde renames
A second family of mistakes comes from the JSON keys themselves. Camel case boundaries, spaces, punctuation, and hyphens all become underscores during normalization, leading digits are prefixed, Rust keywords receive a trailing underscore, and any normalized identifier collision gets a numeric suffix. Whenever the Rust field name ends up different from the original wire key, the generator adds a serde rename attribute so the JSON parser still finds the right field. Read every rename in the output — a field named user_id with #[serde(rename = "userId")] is the correct outcome, and removing the attribute by hand will silently break parsing when the API returns camelCase.
Nested type names are derived safely from their path, so a JSON key like "items" inside a "data" object becomes a struct named DataItems rather than a generic Inner. That naming is collision-safe across most payloads, but if two nested objects truly share a name you will see the numeric suffix in the output — accept it as the warning it is, not as a defect to clean up before testing. The rules themselves come from the Rust identifier reference, so any identifier the generator emits will already be a legal Rust name.
Round-trip real fixtures before adopting the output
Inference cannot replace a test suite. Even after the source compiles, feed it real fixtures that exercise every branch the JSON shape can take: a payload where every optional field is present, one where every optional field is null, one where a required field is missing, and one where a numeric field holds the largest value the API has ever returned. Compile errors and parser errors are the cheapest place to catch a wrong inference, and a passing compile followed by a failed round-trip is exactly the failure mode the table above is designed to prevent. If you are unsure whether the destination project is ready for the generated source, the guide on whether the output compiles without dependencies walks through the Cargo.toml checks in detail.
If round-tripping surfaces a wrong type, edit the generated struct by hand rather than re-pasting a different sample and hoping the converter guesses differently. The generator will faithfully encode whatever the new sample shows, which means swapping one fixture for another can move the same mistake around instead of fixing it. The real fix is almost always upstream: a tighter schema, a documented contract, or a deliberate choice to use serde_json::Value where uncertainty is honest.
When one sample is not enough for an API contract
The last mistake to avoid is the assumption that any generator can replace a written contract. The JSON to Rust Struct Converter is explicitly bounded to one sample, and the source it produces is a translation of that sample, not a definition of the API. A field present here may be optional elsewhere; a small integer may require u64, i128, or a string; a string may represent a UUID, date, URL, enum, borrowed slice, or secret; and mixed objects may deserve a tagged enum rather than a flattened struct. Review authoritative API documentation and several success and failure fixtures, and treat the generated source as the starting point for that review.
For anything that goes into a long-lived crate, prefer the documented types and let the converter help you draft the boilerplate, not author the truth. The destination project needs compatible serde derive support and usually serde_json, and the generator never adds crate paths, module visibility policy, lifetimes, generics, custom serializers, deny_unknown_fields, defaults, flattening, tagging, or validation — those decisions belong to the project owner, not the inference pass. Eight external fixtures lock String, i64, f64, bool, Vec, Option, null, and keyword rename syntax, and additional tests cover nested structs, normalized collisions, and invalid input, so the output you copy is verified against the same rules the table above describes.
If you're weighing options, How to Validate JSON Files in Visual Studio Code covers this in detail.
If you're weighing options, JSON to XML Alternative Built on a Typed Mapping covers this in detail.