A JSON schema package for Go

by Jonathan Amsterdam & Sam Thanawalla, The Go Team

JSON Schema is a specification for describing JSON values that has become a critical part of

LLM infrastructure. We recently released github.com/google/jsonschema-go/jsonschema, a comprehensive JSON Schema package for Go. We use it in the official Go SDK for MCP and expect it to become the canonical JSON Schema package for Google's Go SDKs that work with LLMs.

JSON Schema has been around for many years. Why are we doing this now, and what do LLMs have to do with it?

JSON is a flexible way to describe values. A JSON value can be null, a string, a number, a boolean, a list of values, or a mapping from strings to values. In programming language terms, JSON is dynamically typed. For example, a JSON array can contain a mix of strings, numbers, or any other JSON value. That flexibility can be quite powerful, but sometimes it's useful to constrain it. Think of JSON Schema as a type system for JSON, although its expressiveness goes well beyond typical type systems. You can write a JSON schema that requires all array elements to be strings, as you could in a typical programming language type system, but you can also constrain the length of the array or insist that its first three elements are strings of length at least five while the remaining elements are numbers.

The ability to describe the shape of JSON values like that has always been useful, but it is vital when trying to coax JSON values out of LLMs, whose output is notoriously hard to constrain. JSON Schema provides an expressive and precise way to tell an LLM how its JSON output should look. That's particularly useful for generating inputs to tools, which are usually ordinary functions with precise requirements on their input. It also turns out to be useful to describe a tool's output to the LLM. So frameworks like MCP use JSON Schema to specify both the inputs to and outputs from tools. JSON Schema has become the lingua franca for defining structured interactions with LLMs.

Requirements for a JSON Schema package

Before writing our own package, we took a careful look at the existing JSON Schema packages; we didn't want to reinvent the wheel. But we couldn't find one that had all the features that we felt were important:

  1. Schema creation: A clear, easy-to-use Go API to build schemas in code.
  2. Serialization: A way to convert a schema to and from its JSON representation.
  3. Validation: A way to check whether a given JSON value conforms to a schema.
  4. Inference: A way to generate a JSON Schema from an existing Go type.

We looked at the following packages:

It didn't seem feasible to cobble together what we needed from multiple packages, so we decided to write our own.

A Tour of jsonschema-go

A Simple, open Schema struct

At the core of the package is a straightforward Go struct that directly represents the JSON Schema specification. This open design means you can create complex schemas by writing a struct literal:

var schema = &jsonschema.Schema{
  Type:        "object",
  Description: "A simple person schema",
  Properties: map[string]*jsonschema.Schema{
    "name": {Type: "string"},
    "age": {Type: "integer", Minimum: jsonschema.Ptr(0.0)},
  },
  Required: []string{"name"},
}

A Schema will marshal to a valid JSON value representing the schema, and any JSON value representing a schema can be unmarshalled into a Schema.

The Schema struct defines fields for all standard JSON Schema keywords that are defined in popular specification drafts. To handle additional keywords not present in the specification, Schema includes an Extra field of type map[string]any.

Validation and resolution

Before using a schema to validate JSON values, the schema itself must be validated, and its references to other schemas must be followed so that those schemas can themselves be checked. We call this process resolution. Calling Resolve on a Schema returns a jsonschema.Resolved, an opaque representation of a valid schema optimized for validation. Resolved.Validate accepts almost any value that can be obtained from calling json.Umarshal: null, basic types like strings and numbers, []any, and map[string]any. It returns an error describing all the ways in which the value fails to satisfy the schema.

rs, err := schema.Resolve(nil)
if err != nil {
  return err
}
err = rs.Validate(map[string]any{"name": "John Doe", "age": 20})
if err != nil {
  fmt.Printf("validation failed: %v\n", err)
}

Originally, Validate accepted a Go struct. We removed that feature because it is not possible to validate some schemas against a struct. For example, If a struct field has a non-pointer type, there is no way to determine whether the corresponding key was present in the original JSON, so there is no way to enforce the required keyword.

Inference from Go types

While it's always possible to create a schema by constructing a Schema value, it's often convenient to create one from a Go value, typically a struct. This operation, which we call inference, is provided by the functions For and ForType. Here is For in action:

type Person struct {
    Name string `json:"name" jsonschema:"person's full name"`
    Age int `json:"age,omitzero"`
}

schema, err := jsonschema.For[Person](nil)

/* schema is:
{
    "type": "object",
    "required": ["name"],
    "properties": {
        "age":  {"type": "integer"},
        "name": {
            "type": "string",
            "description": "person's full name"
        }
    },
    "additionalProperties": false
}
*/

For gets information from struct field tags. As this example shows, it uses the name in the json tag as the property name, and interprets omitzero or omitempty to mean that a field is optional. It also looks for a jsonschema tag to get property descriptions. (We considered adding support for other keywords to the jsonschema tag as some other packages do, but that quickly gets complicated. We left an escape hatch in case we decide to support other keywords in the future.)

ForType works the same way, but takes a reflect.Type. It's useful when the type is known only at runtime.

A foundation for the Go community

By providing a high-quality JSON Schema package, we aim to strengthen the entire Go ecosystem for AI applications (and, indeed, any application that needs to validate JSON). This library is already a critical dependency for Google's own AI SDKs, and we're committed to its long-term health. We welcome external contributions, whether they are bug reports, bug fixes, performance enhancements, or support for additional JSON Schema drafts. Before beginning work, please file an issue on our issue tracker.

Campaign and Insertion Order targeting will sunset in Display & Video 360 API and Structured Data Files on February 23, 2026

In November, we announced the upcoming sunset of Campaign and Insertion Order targeting in the Display & Video 360 API and Structured Data Files. This sunset will take place on February 23, 2026 to align with the removal of this targeting in the Display & Video 360 UI.

Starting February 23, 2026, you will see the following behavior when using the Display & Video 360 API and Structured Data Files:

Full details on these changes can be found on our Display & Video 360 API deprecation announcements.

If you need help with these new features, please contact us using our Display & Video 360 API Technical support contact form.

- Trevor Mulchay, Display & Video 360 API Team

Chrome Beta for Desktop Update

The Beta channel has been updated to 145.0.7632.18 for Windows, Mac and Linux.

A partial list of changes is available in the Git log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Chrome Release Team
Google Chrome

Ask Gemini in Google Meet is expanding to Workspace Business Standard customers, additional languages, and mobile usage

In September 2025, we launched Ask Gemini in Meet, which brings the power of Gemini into your organization’s meetings. Today, we’re excited to announce we’re making the feature more broadly available to:

  • Workspace Business Standard customers - Ask Gemini in Meet is currently available to Enterprise customers, and starting in late January, the experience will become available to Business Standard domains as well.
  • An additional seven languages - Ask Gemini in Meet is currently available in English only. Beginning in early February, it will become available in French, German, Italian, Japanese, Korean, Portuguese, and Spanish. The feature supports one language at a time; multiple languages spoken in the same meeting aren't currently supported. More languages will become available in the future.
  • Users on mobile - Also starting in February, Ask Gemini in Meet will become available on the Google Meet mobile app. To access it, tap on the Gemini icon in the top right corner during a meeting.
As a reminder, you use Ask Gemini in Meet to:

  • Get a quick brief on the goals and topics for the meeting you’re in
  • List key takeaways, decisions, and action items mentioned in the meeting
  • Catch up on what you missed if you joined late (as long as Take Notes for Me was enabled)

Getting started

Rollout pace

  • Rapid Release and Scheduled Release domains
    • Expansion to Business Standard: Gradual rollout (up to 15 days for feature visibility) starting on January 26, 2026
    • Additional seven languages: Gradual rollout (up to 15 days for feature visibility) starting on February 2, 2026
    • Meet mobile app: Gradual rollout (up to 15 days for feature visibility) starting on February 9, 2026

Ready to review some changes but not others? Try using Play Console’s new Save for later feature

Posted by Georgia Doyle, Senior UX Writer and Content Designer, and Kanu Tibrewal, Software Engineer



We’ve launched a new Save for later feature on Google Play Console’s Publishing overview to give you more control over when you send changes for review. 


In the past, changes to your app were bundled together before being sent for review. This presented challenges if you needed to reprioritize changes, or if the changes were no longer relevant. For example, updates to your test tracks grouped with marketing changes that need to be rescheduled. This lack of flexibility meant that if some changes were ready for review but not others, you could end up delaying urgent fixes, or publishing changes that you weren’t quite ready to make.

Now, you have the ability to hold back the changes you’re not ready to have reviewed.

How it works

In the 'Changes not yet sent for review' section of the Publishing overview page, select ‘Save for later’ on the groups of changes that you don’t want to include in your next review. You can view and edit the list of saved changes, and return them to the Publishing overview if you change your mind. Once the review has started, your saved changes will be added back to ‘Changes not yet sent for review’.


Integration with our pre-review checks


Save for later also works with our pre-review checks. Pre-review checks look for issues in your changes that may prevent your app from being published, so that you can fix them before you send changes for review. If checks find issues with your app, there are two ways you can proceed:

  • If issues are isolated to an individual track, we’ll show you an error beside that change, so you know what to save for later in order to proceed to review with your other changes.
  • If you have issues that affect your whole app, for example, App content issues, Save for later will be unavailable and you will need to fix them before you can send any changes for review.

Greater flexibility in your workflows

Our goal for Save for later is to give you greater flexibility over your release schedule. With this feature you can manage what changes you send for review, and address issues affecting individual tracks without holding up ready-to-release changes, so you can iterate faster and minimize the impact of rejections on your release timeline.

So, what's next?

We're committed to continuously improving your publishing experience. Save for later is a significant step towards providing you with more granular control over this all-important stage in the journey to publishing your app. We'll continue to gather your feedback and look at ways we can provide greater flexibility to the review and publishing process.

We're excited to see how Save for later helps you to streamline your release process and bring your app innovations to users even faster.

Ready to review some changes but not others? Try using Play Console’s new Save for later feature

Posted by Georgia Doyle, Senior UX Writer and Content Designer, and Kanu Tibrewal, Software Engineer



We’ve launched a new Save for later feature on Google Play Console’s Publishing overview to give you more control over when you send changes for review. 


In the past, changes to your app were bundled together before being sent for review. This presented challenges if you needed to reprioritize changes, or if the changes were no longer relevant. For example, updates to your test tracks grouped with marketing changes that need to be rescheduled. This lack of flexibility meant that if some changes were ready for review but not others, you could end up delaying urgent fixes, or publishing changes that you weren’t quite ready to make.

Now, you have the ability to hold back the changes you’re not ready to have reviewed.

How it works

In the 'Changes not yet sent for review' section of the Publishing overview page, select ‘Save for later’ on the groups of changes that you don’t want to include in your next review. You can view and edit the list of saved changes, and return them to the Publishing overview if you change your mind. Once the review has started, your saved changes will be added back to ‘Changes not yet sent for review’.


Integration with our pre-review checks


Save for later also works with our pre-review checks. Pre-review checks look for issues in your changes that may prevent your app from being published, so that you can fix them before you send changes for review. If checks find issues with your app, there are two ways you can proceed:

  • If issues are isolated to an individual track, we’ll show you an error beside that change, so you know what to save for later in order to proceed to review with your other changes.
  • If you have issues that affect your whole app, for example, App content issues, Save for later will be unavailable and you will need to fix them before you can send any changes for review.

Greater flexibility in your workflows

Our goal for Save for later is to give you greater flexibility over your release schedule. With this feature you can manage what changes you send for review, and address issues affecting individual tracks without holding up ready-to-release changes, so you can iterate faster and minimize the impact of rejections on your release timeline.

So, what's next?

We're committed to continuously improving your publishing experience. Save for later is a significant step towards providing you with more granular control over this all-important stage in the journey to publishing your app. We'll continue to gather your feedback and look at ways we can provide greater flexibility to the review and publishing process.

We're excited to see how Save for later helps you to streamline your release process and bring your app innovations to users even faster.