b2KIT

Schema.org Type Reference

Browse and search Schema.org types and properties with examples, required fields, and hierarchy navigation.

Tested tool guide Tested browser tools Checked August 16, 2026

What Schema.org Type Reference does, with a checked example

A lookup tool for the Schema.org vocabulary, the shared structured-data standard behind most rich results in search engines. Type a name, such as Movie, isbn, or recipe, and the page returns the matching type or property: where it sits in the hierarchy rooted at the type Thing, the properties it accepts, each property's expected value types, and worked examples in JSON-LD and Microdata. Because the tool mirrors the published vocabulary, the definition it shows is the one any consumer will apply. The usual surprise: Schema.org marks nothing as required. No property is formally mandatory, so a 'required' annotation reflects a consumer such as Google's rich-results documentation, not the schema itself.

Worked example

A concrete input and expected output from the current implementation.

Input

Movie

Expected output

The Movie entry shows hierarchy Thing to CreativeWork to Movie; direct properties such as actor (Person), director (Person), duration (Duration), genre (Text or URL), productionCompany (Organization), and trailer (VideoObject), plus inherited properties like name and datePublished (Date); and an example JSON-LD block:
{
  "@context": "https://schema.org",
  "@type": "Movie",
  "name": "Inception",
  "director": { "@type": "Person", "name": "Christopher Nolan" },
  "datePublished": "2010-07-16"
}

The entry mirrors schema.org/Movie: the type descends from CreativeWork, and director's expected type is Person, so the example nests a Person object instead of a plain string. The release date is Inception's actual US premiere, July 16, 2010, so the sample validates against the vocabulary.

How the result is produced

1

Hierarchy-first lookup

Every type in the vocabulary descends from the root type Thing, usually through several levels, and opening a type shows that ancestry. The property list then presents direct properties together with inherited ones from supertypes, so the entry reflects exactly what the type accepts in markup. The tree also helps you move down when a general type such as Event is too broad for your content.

2

Matching names, not text

Search compares against type and property names, camelCase and exact, and labels each hit as a type or a property. Property hits show the value types they accept, such as Person, Text, or URL, plus the types they belong to. Schema.org assigns properties to types through domainIncludes rather than strict domains, so one property can be valid across many unrelated types, and the entry lists every one.

Good uses

  • Writing JSON-LD for a page and needing the exact camelCase name and expected type of a property, such as confirming that director expects a Person object and not a plain string.
  • Choosing which type to mark up by comparing subtypes, for example Event versus its subtype MusicEvent, to carry the extra fields the more specific type allows.
  • Half-remembering a property such as author and checking whether it exists, what values it accepts, and every type it may be attached to.

Limits and checks

  • Expected types are not requirements. They state which value shapes a property accepts, and the vocabulary never marks any property mandatory, so an entry with no required annotation is normal and complete rather than unfinished.
  • Names are case-sensitive and one token: datePublished and date_published are different, and only the first exists. A spaced or underscored query can return no match even though the property is in the vocabulary.
  • The vocabulary is versioned and layered. Some entries live in the pending layer as drafts or in named extensions such as health-lifesci or auto, so a type present in the reference may not yet be supported by consumers.

Common questions

Why is nothing marked required on the Person entry? I thought structured data had required fields.

The Schema.org vocabulary itself has no required properties; nothing in it is formally mandatory, and the schema's own examples are often minimal. Required and recommended lists come from consumers, chiefly Google's rich-results documentation, and they vary by feature. If you need that list, look it up for your specific feature rather than expecting the reference to supply it.

Can I pull the entire vocabulary into my project instead of browsing it here?

Yes, and that is the better route for anything programmatic. The maintainers publish the complete ontology as machine-readable dumps, including Turtle, N-Triples, and JSON-LD, plus a full hierarchy listing, all linked from the official developers page. A reference browser is for reading; a build that validates or generates markup should consume those files.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools