{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}{{ badge.value }}
{{ sourceHelp }}
{{ sourceMeta }}
{{ fileStatus }}
Choose the grammar explicitly; source text is parsed locally and never executed.
For example: models, api, config, or store.
Use a domain name such as Order, Account, Event, or CatalogItem.
Choose the database that owns the CREATE TABLE statement.
Choose only the tags your downstream code will use.
Pointers are the safe scaffold default; choose values only when zero values are acceptable.
Keep integer evidence when useful, or use float64 to mirror generic encoding/json number handling.
{{ inferTimeEnabled ? 'Infer time.Time' : 'Keep strings' }}
Off preserves strings exactly; enable only when the API contract confirms timestamps.
{{ sortFieldsEnabled ? 'Alphabetical' : 'Source order' }}
Keep source order by default, or sort generated fields for stable review diffs.
{{ computation.values.go_struct_source }}

The chart renderer is unavailable. Type counts remain available in the field mapping.

SourceGo fieldGo typeTagsCopy
{{ row.source_path }}{{ row.go_field }}{{ row.go_type }}{{ row.tags || '—' }}
  • {{ note }}

No ambiguous mappings were found in this sample. Compare the generated fields with the authoritative API or database schema before use.

JSON to TypeScript Converter Turn JSON or JSON Lines samples into TypeScript declarations with configurable null and optional-property policies plus array inference and runtime guards.
JSON Converter Convert JSON or JSON Lines into tables and handoff text with record-path selection, flattening controls and warnings for sparse or risky data.
JSON Formatter Format JSON for review or transport, inspect its structure and byte size, and flag duplicate keys or precision risks before reuse.
JSON Schema Generator Turn sample JSON into a draft-aware JSON Schema with explicit inference choices and review warnings for assumptions that need broader test data.

A Go struct describes a record as named fields with declared types. It can model an API payload, configuration document, database row, or another data shape, but the declaration is only useful when its field types match the real contract. Sample-driven generation shortens the first draft; it cannot prove what future records are allowed to contain.

JSON and SQL provide different kinds of evidence. JSON contains values, so a generator infers types from examples: a whole number suggests an integer, a quoted value suggests a string, and an object suggests another struct. A CREATE TABLE statement declares column types and nullability more directly, but its database types still need deliberate Go equivalents.

SourceStrong evidenceMissing evidenceMain review risk
Representative JSONObserved keys, nested shapes, values, nulls, and array membersUnseen optional fields, full numeric ranges, and future variantsA narrow sample can produce a type that is too strict.
SQL table definitionDeclared column types, order, and basic nullabilityApplication validation, joins, generated behavior, and custom scanning rulesA database type may not have a lossless standard Go equivalent.

Nullability is a modeling decision, not a cosmetic style. A pointer can distinguish an absent or SQL NULL value from a type's zero value. A value field is simpler to use, but it merges those states. The right choice depends on the API or database contract and on how decoding or row scanning is handled in the project.

Struct tags preserve source field names after they are converted to exported Go identifiers. A key such as display_name can become DisplayName while a JSON or database tag keeps the original spelling. Tags do not validate data, rename database columns, or select an object-relational mapper; downstream code decides how to interpret them.

Numbers deserve extra caution. JSON has a single number grammar, while Go distinguishes integer and floating-point types. SQL decimal types may represent exact financial quantities that should not be stored in float64. Generated numeric fields are scaffolding until the authoritative schema, expected range, precision, and null behavior have been checked.

Generated source should compile cleanly, but compilation alone is not contract verification. Compare every field with API documentation, schema migrations, representative edge cases, and project-specific types before adding the declaration to production code.

How to Use This Tool:

Choose the grammar that owns the source, then review the generated mapping as a draft of the real data contract.

  1. Select Representative JSON or SQL CREATE TABLE. JSON accepts one object or an array of objects; SQL accepts one PostgreSQL or MySQL table statement.
  2. Paste the source, then enter a valid lower-case Package name and an exported Root type name. In SQL mode, select the database dialect instead of relying on type-name guessing.
  3. Choose the struct tags needed by downstream code. Use JSON tags, database tags, both, or no tags.
  4. Set the nullable and JSON number policies. Enable timestamp inference only when the source contract confirms that matching strings are timestamps; sort fields only when alphabetical order is preferred over source order.
  5. Inspect Field mapping and Review notes before copying the Go source. Resolve mixed types, missing fields, unsupported SQL types, decimal precision, and zero-value warnings against the authoritative contract.

Interpreting Results:

Go struct source is a compilable scaffold containing the package clause, any required standard-library imports, and generated struct declarations. Field mapping is the audit trail: it connects each source path or column to its exported field, Go type, and tags. Review that table before focusing on the type-count chart.

Review notes identify evidence that cannot safely resolve itself, including missing or null JSON values, mixed sample types, empty arrays, renamed fields, unsupported SQL types, decimal-to-floating-point mappings, and nullable fields emitted as values. A result with no notes still reflects only the supplied sample or table statement.

The type profile shows how many fields use each generated type. It can reveal an unexpected concentration of any or pointers, but it does not rank correctness. Verify types against the contract, run the project's formatter and compiler, and test decoding or database scanning with edge cases.

Technical Details:

Generation is a bounded source-to-type transformation. JSON values are merged into a structural shape before names and Go types are allocated. SQL columns are parsed from one table definition and mapped according to the chosen database dialect. Both paths finish by applying nullability, tags, field order, imports, and Go identifier rules.

Transformation Core

StageJSON pathSQL path
ParseRead one object or a non-empty array of objects.Read one CREATE TABLE column list and the selected dialect.
Collect evidenceWalk nested values and merge up to 100 array samples.Read column names, declared types, NOT NULL, and primary-key markers.
Resolve shapeMerge compatible types; mark missing or null fields as nullable.Map database types to Go types and mark other columns nullable.
NameConvert source names to exported identifiers, preserve common initialisms, and resolve collisions with numeric suffixes.
EmitApply pointer or value policy, add selected tags and imports, then write package and struct declarations.

Rule Core

JSON inference uses observed values. When several samples reach the same path, their shapes are merged under these rules.

JSON evidenceGenerated base typeMerge or review behavior
StringstringA parseable timestamp-like string becomes time.Time only when timestamp inference is enabled.
BooleanboolMixed with another kind, it becomes any.
Whole numberint64 or float64The JSON number policy decides the starting type; integer plus decimal evidence becomes float64.
Decimal numberfloat64Range and precision still require contract review.
ObjectNested structFields are merged across object samples; an absent field becomes nullable.
ArraySlice of the merged item typeAn empty array becomes []any; at most the first 100 items are sampled.
nullNullable matching type, or any without other evidencePointer mode adds a pointer only when the resolved type is pointer-eligible.
Incompatible kindsanyA review note records the mixed evidence.

SQL mapping follows declared type families. PostgreSQL arrays add a slice around the mapped element type. Table-level constraints are skipped, while inline NOT NULL and primary-key markers make a column required.

Go typePostgreSQL examplesMySQL examplesReview note
intsmallint, integer, serialtinyint, smallint, mediumint, intMySQL tinyint(1) maps to bool.
int64bigint, bigserialbigint, yearConfirm unsigned ranges and project conventions.
float64real, double precision, numeric, moneyfloat, double, decimal, fixedExact decimal-like types generate a precision warning.
stringText, character, UUID, network, XML, interval, and name typesCharacter, text, enum, and set typesDatabase-specific validation is not reproduced.
time.TimeDate, time, timestamp, and time-zone variantsdate, datetime, timestamp, timeThe time import is added.
json.RawMessagejson, jsonbjsonThe encoding/json import is added.
[]bytebyteaBinary, blob, and bit familiesEncoding and scanning behavior remain project concerns.
anyAny unsupported declared typeReplace it with the project's real type before use.

Names are split at punctuation and case changes, converted to exported Go form, and normalized for common initialisms such as ID, URL, HTTP, JSON, SQL, and UUID. Leading digits are removed. A keyword-like name receives a Value suffix, and generated collisions receive numeric suffixes. Tags keep the original source spelling.

BoundaryMaximumEffect
Source100,000 charactersLarger input is rejected.
JSON depth20 levelsDeeper samples are rejected.
Sampled JSON values5,000 nodesMore complex samples are rejected.
Fields or SQL columns1,000Larger models are rejected.
Generated structs80Additional nested types are not emitted.
Array evidenceFirst 100 items per sampled arrayLater variants do not influence inference.
Generated source200,000 charactersOversized output is rejected.
Visible review notes30 distinct notesAny additional note count is summarized.

Source text is parsed locally as inert data or data-definition language. It is never executed, and SQL defaults, indexes, foreign keys, checks, generated expressions, methods, migrations, and object-relational behavior are not turned into Go code.

Accuracy Notes:

The output reflects supplied evidence, not the full runtime domain. Before use, confirm:

  • optional and nullable fields against the API schema or database migration;
  • integer ranges, exact decimals, identifiers, enums, timestamps, and custom scalar types;
  • whether pointers, value types, or dedicated nullable wrappers match decoding and database-scanning conventions;
  • that every generated tag is used by the intended serializer or database library;
  • that root arrays and large nested arrays included enough varied records to expose optional and mixed fields.

Worked Examples:

Mixed JSON order samples

An array contains two order objects. The first has an integer quantity and no note; the second has a decimal quantity and a null note. Quantity becomes float64, note is nullable, and the review notes record both the mixed numeric evidence and the missing or null field. Those cues should be checked against the API schema before the generated types are accepted.

PostgreSQL invoice table

A table declares id bigint PRIMARY KEY, total numeric(12,2) NOT NULL, and nullable metadata jsonb. The draft uses int64 for ID, float64 for total with an exact-decimal warning, and a pointer to json.RawMessage for metadata under the pointer policy. A money-safe decimal type may be the necessary correction.

References: