JSON to Go Struct

Q: Why are some fields pointers?

Because Go has no undefined, so without a pointer you cannot tell a missing key from a zero value. If a field is absent in some records, decoding into a plain string leaves it as the empty string — identical to a record that genuinely sent an empty string. A *string is nil when the key was absent and points at a value when it was present, which preserves the distinction the JSON carried. It costs you a nil check at every use, which is exactly the point: the data really is sometimes missing.

Q: What are the struct tags for?

They preserve the original key. Go only encodes and decodes exported fields, which must start with a capital letter, so first_name has to become FirstName in the struct. Without a json:"first_name" tag, the standard library looks for a key called FirstName in your JSON, does not find it, and silently leaves the field empty — no error, just missing data. The tag is the only thing connecting the Go name to the wire format, so never delete one.

Q: Why is every number a float64?

Because JSON has a single number type and nothing in the document says whether a value is an integer. A sample containing 1 could be an id that is always whole, or a quantity that is sometimes 1.5 — and choosing int for the first case breaks the moment a decimal arrives. float64 round-trips every value JSON can represent, so it is the safe default. Change it to int64 by hand where you know the field is genuinely integral; that is a decision only you can make.

Q: What does omitempty actually do?

It applies when encoding, not decoding: a field with omitempty is left out of the output entirely if it holds its zero value. That is usually what you want for an optional field, since emitting "nickname": "" is different from omitting it. The trap is that omitempty treats every zero value the same, so a genuine false or a genuine 0 also disappears. Combined with a pointer this behaves correctly — nil is omitted, a pointer to false is not.

Q: Why did a field become interface{}?

Because the sample showed more than one type for it and Go has no union type. If a field is a number in one record and a string in another, there is no single Go type that describes both, so interface{} is the honest answer — and a type switch at the point of use is the honest handling. It is usually worth treating this as a finding rather than a result: inconsistent types in an API response are often a bug on the producing side that is easier to fix there.

Q: Should I generate types or write them by hand?

Generate as a starting point, then edit. A generator gets the shape right and saves the tedious transcription, which is most of the work for a large payload. What it cannot know is your intent: which numbers are really integers, which strings are really enums, which fields you want to rename for clarity, and where a custom UnmarshalJSON belongs. Treat the output as a first draft that is structurally correct rather than as a finished model.

Generate Go structs from a JSON sample, with json tags, pointers for optional fields and nested types extracted.

JSON sample

Root struct name

Pointers for optional fields Add omitempty

Generation happens entirely in your browser, so a real API response never leaves your machine.

What It Does

Paste a JSON response and get the Go structs that decode it. Two details separate this from a straight transliteration. First, a key that appears in some array elements but not others becomes a pointer, because Go has no undefined and a plain string cannot distinguish a missing key from an empty one — that distinction was in your JSON and it should survive into your types. Second, every field carries a json tag with its original name, because Go can only encode exported fields and FirstName will silently fail to match first_name without one. Nested objects are extracted into their own named structs, identical shapes are reused rather than duplicated, and array element types are named in the singular so the code reads naturally.

When to Use It

You are consuming a third-party API in Go and need the structs for a response with forty fields.
A webhook payload needs a type to decode into and you have a sample of the real thing.
You want to check whether an API's response is consistent before writing code that assumes it is.
A configuration file in JSON needs a matching Go type for loading at startup.
You are writing tests and need a struct that matches a fixture you already have.

Worked Examples

{"user_id":1,"first_name":"Jane","is_active":true}

Shows the tag rule clearly. Every field is renamed to its exported form and tagged with the original key — without those tags the standard library would look for UserId in the JSON and find nothing.

[{"id":1,"nickname":"jo"},{"id":2}]

The pointer case. Nickname is absent from the second record, so it becomes a *string with omitempty — which is the only way Go can tell "not sent" from "sent as empty".

{"page":1,"results":[{"id":9,"author":{"name":"Jane"}}]}

Nesting. The result element becomes its own Result struct named in the singular, the author becomes an Author struct, and the outer type references both rather than inlining them.

Features

Go structs with json tags on every field

Pointers for optional and nullable fields

omitempty added where a field is optional

Nested objects extracted into named structs

Identical shapes reused rather than duplicated

Array element types named in the singular

Exported field names generated from any key style

Union fields reported rather than silently flattened

Pointers can be disabled if you prefer plain types

Runs entirely in your browser

How to Use

1. Paste your JSON — a full array of records gives the best result, since that is what reveals optional fields. 2. Set a name for the root struct. 3. The Go code appears immediately below. 4. Adjust the pointer and omitempty options to match your codebase's conventions. 5. Copy the structs, then change float64 to int64 wherever you know the field is integral.

Common Mistakes

Deleting the struct tags. Go looks for the tagged name when decoding, so removing them makes every snake_case field silently stay empty with no error at all.
Using a plain type for an optional field. Without a pointer, a missing key and an empty value are indistinguishable, and code downstream cannot tell which it got.
Leaving lowercase field names. Unexported fields are invisible to encoding/json entirely, so they neither encode nor decode.
Assuming float64 is wrong and changing everything to int. It is the safe default because JSON has one number type — change it only where you know the value is always integral.
Treating generated structs as finished. They are structurally correct but know nothing of your intent about enums, renames or custom unmarshalling.

Frequently Asked Questions

Why are some fields pointers?

What are the struct tags for?

Why is every number a float64?

What does omitempty actually do?

Why did a field become interface{}?

Should I generate types or write them by hand?