We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Automatically convert JSON data structures into Smithy IDL model definitions to simplify your API design and service modeling workflow.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
This converter reads a JSON sample and infers a draft of Smithy model text from the values and structure it can see. It is intended for developers who have an example payload and want a first pass at its data shapes before editing a model. You can rename the top-level type (initially Root) and choose whether to generate type definitions only. The generated text can be copied or downloaded as a .smithy file.
Smithy is a modeling language for describing service interfaces and data structures. In Smithy IDL, a structure groups named members, a list represents an ordered collection, and a map represents key-to-value entries. The output is an inferred data-model draft based on the supplied sample; it does not create a complete service API or establish that the model passes Smithy validation. Smithy’s model specification describes the broader semantic model, while its IDL specification defines the text syntax. Both checked October 2, 2026.
A sample shows the fields and value forms present in that particular example. It cannot by itself establish every field that may appear, whether a field is optional, or the full range of values used by a service. A populated nested object gives the generator evidence about its members; an empty array supplies no element example to inspect. Treat the result as a sketch to compare with your API contract, not as a substitute for that contract.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Use syntactically valid JSON with double-quoted property names and strings. Include realistic nested objects and array elements when those shapes matter. If your payload varies across responses, review more than one representative case in your design process; one submitted example cannot describe unseen variants.
Replace Root with a name that fits the model you are drafting, such as Order or Profile. Keep the name consistent with your project’s naming conventions.
The Smithy option includes a “Just Type Definitions” setting. Review the generated definitions against the sample and the interface contract, especially nested data and arrays. Copy the text or download the .smithy file, then validate and refine it with the Smithy tools and conventions used by your project.
Use cases
See how the tool fits into real work and everyday tasks.
An API developer with a representative response can generate a first outline of its data model, then compare each member and nested collection with the service documentation before committing any definition.
A teammate can bring generated Smithy text to a design review as a concrete discussion aid. The group can decide which fields are required, what constraints apply, and which variants need separate examples based on the real contract.
Q&A
Find concise answers to common questions and confusing cases.
No. It is a data-model draft inferred from one JSON sample. Service and operation definitions, documentation, traits, namespace choices, and other contract details require separate modeling work.
The sample only demonstrates the values it contains. Another response may omit a field or use a different value form. Check the generated member types against the API contract and additional representative payloads.
Add a representative element to the sample if you know the intended structure, or edit the inferred member type yourself. An empty array has no element fields from which to infer a nested shape.
Check that the input is complete JSON: braces and brackets must pair, strings need double quotes, and commas must separate members without a trailing comma. Correct syntax errors before assessing the generated model.
Notes
Review scope, result limitations, and important precautions before use.
Inference is limited to the information in the sample and does not certify Smithy syntax, semantic validity, compatibility, or suitability for production. Confirm field meaning, optionality, null handling, allowed values, and cross-response variants using the service’s actual contract. Add any required traits, documentation, namespace, service, and operation definitions, then run the validation workflow adopted by your project.
Do not paste secrets, access tokens, or personal data into sample payloads. Use minimized or synthetic examples when the original values are not needed to infer structure.
Related
Discover related tools, collections, and available API capabilities.