b2KIT

Person Schema Builder

Generate Person schema markup with bio, job title, social profiles, and images. Build personal brand entity data.

Tested tool guide Tested browser tools Checked August 16, 2026

What Person Schema Builder does, with a checked example

Turns the details behind a personal brand - name, job title, employer, bio, photo, and social-profile URLs - into a Person JSON-LD block you can paste into a page's head. Each field maps to its schema.org property, and the builder serializes the result with @context and @type set, wrapped in a script tag with the values JSON-escaped. The common mistake is expecting search badges: Google stopped powering author-byline rich results from this kind of markup years ago, so judge the output by entity clarity, not by a visible result.

Worked example

A concrete input and expected output from the current implementation.

Input

Name: Mara Chen
Job title: Senior Product Designer
Employer: Northwind Studio
Bio: Product designer working on developer tools.
Website: https://marachen.example
Photo: https://marachen.example/avatar.jpg
Social profiles: https://www.linkedin.com/in/marachen, https://x.com/marachen

Expected output

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Mara Chen",
  "jobTitle": "Senior Product Designer",
  "worksFor": {
    "@type": "Organization",
    "name": "Northwind Studio"
  },
  "url": "https://marachen.example",
  "image": "https://marachen.example/avatar.jpg",
  "description": "Product designer working on developer tools.",
  "sameAs": [
    "https://www.linkedin.com/in/marachen",
    "https://x.com/marachen"
  ]
}
</script>

Every input maps to a documented Person property: the social URLs land in sameAs, the reserved property for accounts of the same person, and the employer stays a separate nested Organization. The @context and @type keys are what make the object JSON-LD, and parsers ignore property order.

How the result is produced

1

Field-to-property mapping

Each field maps to a documented Person property: the name becomes name, the job title becomes jobTitle, the employer becomes a minimal Organization nested under worksFor, and each social profile becomes an entry in sameAs, the property reserved for URLs of accounts that belong to the same person. Bio, photo, and website map to description, image, and url.

2

Serialization and output

The builder serializes the entity as JSON-LD: a single JSON object opening with "@context": "https://schema.org" and "@type": "Person", wrapped in a <script type="application/ld+json"> element for pasting into a page head. String values are JSON-escaped so quotes cannot break out of the script block, and the snippet is formatted for direct placement in the HTML.

Good uses

  • Marking up an author on a blog or article page so the person behind the content is described once, in machine-readable form.
  • Publishing a personal profile page whose social profiles - LinkedIn, X, GitHub - are collected into sameAs for a single, explicit identity record.
  • Adding a person entity to a portfolio or agency About page, tying job title, employer, photo, and website into one addressable entity.

Limits and checks

  • Valid JSON is not a visible result. The output can be flawless and still show no rich result anywhere - author-byline rich results no longer exist - so validity alone tells you nothing about what the markup does on a page.
  • The builder copies what you type. A placeholder name, a relative image path, or a typo in a social URL becomes part of the published entity, so proofread the values you entered, not just the JSON that came out.
  • Person describes one specific person. A generic label like "the author," or naming the person differently from page to page, fragments the entity instead of consolidating it - the markup only helps when name and URLs stay consistent across the site.

Common questions

Will Google show an author byline or profile card if I add this markup?

Not as a matter of course. Google stopped displaying author-byline rich results from this kind of markup years ago, and its current Profile pages documentation targets dedicated profile pages with requirements of its own. The realistic payoff is a clean, explicit entity description that search engines and other structured-data consumers can read. Validate the JSON, but expect clarity rather than a badge.

Which social profiles should I put in sameAs?

The ones that genuinely belong to the person and are still maintained: a LinkedIn profile, an X account, a GitHub, a portfolio. schema.org and Google's profile-page guidance both treat sameAs as links to accounts identifying the same person, so include real, live profiles and leave out abandoned or lookalike ones. A short, accurate list beats a long one.

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