Unisex sizing guide for Shopify merchants: implementation blueprint

Unisex sizing guide for Shopify merchants: implementation blueprint

Normalise every alpha and numeric size into a single internal scale, expose per-product size charts through Shopify metafields or metaobjects, and build a product-truth layer before switching on any AI try-on tool. That is the whole job in one sentence. Everything else in this unisex sizing guide is about executing those three pillars without breaking your catalogue.

Start this week with three actions:

• Define your measurement points and grading rules per category (tops, bottoms, shoes).
• Build size-chart JSON objects with consistent mapping keys.
• Add a product.metafields.sizing.chart definition and write the guarded render logic.

Shopify metafields are the delivery mechanism, size-normalisation research from Zalando underpins the mapping logic, and GarmCheck is the recommended integration once your data is clean.

Key Takeaways

A reliable unisex sizing system depends on category-first normalisation, merchant-editable Shopify metafields, and a synced product-truth layer before any AI try-on tool goes live.

Point Details Normalise by category Map tops, bottoms and shoes onto separate one-dimensional scales, not one shared chart. Store charts as structured data Use JSON or metaobjects with an explicit lookup order: SKU, then handle, then category mapping. Render charts near the decision point Place the metafield-driven chart beside the variant picker, guarded against blank content. Build the product-truth layer first Sync SKU metadata, measurements and image eligibility before enabling AI try-on. Pilot before scaling Test on one or two collections and track fit-related return share before a catalogue-wide rollout. Pair charts with automated fit tools GarmCheck’s virtual try-on and size recommendation run on the same measurement data once your catalogue is normalised.

Table of Contents

• Why a unisex sizing guide matters to retailers and engineering teams
• Size normalisation: mapping and grading rules for unisex sizes
• Data structures: JSON schema, namespacing and caching
• Shopify implementation: metafields, metaobjects and Liquid
• Building a product-truth layer for AI try-on and sizing
• Testing, metrics and rollout phases for sizing systems
• Governance: roles, quality gates and catalogue hygiene
• What makes unisex sizing different from gender-specific sizing?
• How should shoppers convert between men’s, women’s and unisex sizes?
• Common challenges and limits of unisex sizing
• Popular unisex sizing chart formats by apparel type
• What experienced merchants get wrong about unisex sizing
• How GarmCheck fits into this blueprint
• Sources

Why a unisex sizing guide matters to retailers and engineering teams

A disciplined sizing system cuts fit-driven returns and lifts conversion, because shoppers who can’t tell if a “unisex M” fits them simply don’t buy, or buy two sizes and send one back. The two operational problems behind this are consistent: inconsistent alpha and numeric labels across brands, and category differences between tops, bottoms and shoes that a single flat chart can’t capture.

There’s also a hidden bottleneck. Most catalogues aren’t ready for AI-driven fit tools because product data was never structured for machine reading in the first place.

• Poor fit is the dominant driver of fashion returns , which makes size-chart quality a revenue lever, not a housekeeping task.
• Numeric size 10 in one brand’s unisex line can equal a different chest measurement entirely in another’s, so string matching alone will mislead customers.
• Shoes, tops and bottoms need separate grading logic; treating them as one sizing problem is the single most common structural mistake merchants make.

Size normalisation: mapping and grading rules for unisex sizes

Normalise by category first, then map every brand-specific size string into that category’s one-dimensional scale. Don’t try to solve tops, bottoms and shoes with one shared scale. They grade differently and merging them produces false confidence.

Group raw size strings into “size types”: alpha (XS to XXL), numeric (28 to 44), plus, and half-sizes. Zalando’s approach to this problem builds a frequency matrix from co-purchase data (which sizes customers buy or exchange together) and solves a scalar mapping through an optimisation objective, and research from Zalando shows this method approaches human-annotator accuracy once the dataset is large enough. You don’t need transaction-scale data to borrow the principle: define the size types explicitly, then map every SKU into them rather than trusting the label on the product page.

Record your grading points in centimetres, using a half-body convention (measuring one side of a garment laid flat) unless a supplier explicitly gives full-body figures. A machine-readable measurement dataset is a useful baseline here, and defines 41 measurement points across regions. For unisex apparel you typically need:

• Chest or bust circumference
• Waist circumference
• Hip circumference
• Sleeve length
• Inseam
• Foot length (footwear only)

Build a fallback lookup order for exceptions: SKU mapping first, then product handle, then category-level mapping, then a default chart. This precedence matters more than any single measurement definition, because long-tail SKUs will always break your first pass.

Pro Tip: Start normalisation with tops and fitted bottoms, since they carry the highest return risk. Leave shoes and loose-fit categories for a later phase; the mapping logic is simpler there and the payoff is smaller.

Data structures: JSON schema, namespacing and caching

Use a hybrid model: canonical size charts live as JSON or metaobjects, and individual products carry references rather than duplicated chart content. This keeps a single source of truth while letting exceptions override cleanly.

Normalise gender labels inside the schema itself, using “unisex” as a distinct, explicit value rather than inferring it from a missing men’s or women’s field.

Field Purpose id Unique chart identifier name Human-readable chart label category tops / bottoms / shoes itemType e.g. hoodie, chino, trainer gender men / women / unisex (explicit value) tableHtml Rendered chart markup measurementGuide How-to-measure copy gradingRules Increment logic between sizes

Lookup order matters as much as the schema. A size-chart architecture pattern that works well in production resolves in this order: sizechart:sku:{sku} → sizechart:handle:{handle} → sizechart:mapping:{category}:{productType}:{gender} .

• Cache resolved charts at the edge, since chart content changes rarely and doesn’t need per-request computation.
• Keep an embedded default chart in code as a fallback if the cache layer fails, so a broken lookup never means a blank size guide on a live product page.

Shopify implementation: metafields, metaobjects and Liquid

Put the chart in a product metafield, rich text for a fast start or a metaobject reference once you’re managing shared charts across a catalogue, and render it next to the variant picker, using this Size Chart guide from Darius Cordell . That placement matters: sizing information shown below the fold or buried in a tab gets ignored at the exact moment a shopper is deciding.

• Create a metafield definition under a clear namespace, for example sizing.chart .
• Choose the type: Rich text for single-product charts, Metaobject reference when several products share one chart.
• Populate charts per product or per category using Shopify’s bulk editor, or assign by collection tag.
• Render the chart only when the metafield isn’t blank, using a guarded check inside a native <details> panel so the page doesn’t show an empty accordion.
• Give each rendered chart a unique ID if a theme has multiple product modals open simultaneously.

For variant-linked charts, detect the selected variant with a small JavaScript hook and swap the chart by handle or SKU, following the same lookup precedence defined earlier. This is the professional Shopify pattern for merchant-editable size charts: metafield in, guarded snippet out, no developer needed for routine updates.

Approach Best for Trade-off Rich text metafield Single product, fast launch Duplicated content across similar products Metaobject reference Shared charts across a catalogue Slightly more setup time upfront Hardcoded theme snippet Never recommended Requires a developer for every chart change

Pro Tip: For catalogues above a few hundred SKUs, go straight to metaobject plus product reference. The bulk editor lets you assign charts by collection in minutes, and you avoid the rework of migrating rich-text charts later.

Building a product-truth layer for AI try-on and sizing

Before connecting any AI model, build a product-truth layer: SKU-level metadata, garment measurements, qualifying image assets and an eligibility flag, all synced automatically. Manual, one-off setup is a frequent cause of failed try-on deployments , because catalogues drift out of sync with the model pipeline within weeks of launch.

Mandatory fields for the product-truth record:

• SKU, category and item type
• Garment measurements in centimetres
• Fabric stretch percentage
• Primary image and detail images
• Critical features (zips, hoods, structured shoulders)
• try_on_eligible flag and a risk-level tag

Image assets need consistent lighting, a fixed crop, background removal where the model requires it, and a minimum resolution that holds up at product-page zoom. Model-on and flat-lay shots both need standard poses, or the try-on renders will look inconsistent between SKUs on the same collection page.

Sync this layer with your AI pipeline through webhooks or a scheduled metadata export, and never enable try-on for SKUs missing garment measurements. That single guardrail avoids most of the visible quality failures merchants report after launch.

The most common cause of an unreliable try-on rollout isn’t the AI model. It’s a catalogue that was never structured to feed one.

GarmCheck’s Shopify integration is built around exactly this product-truth requirement, pulling body measurements from a customer photo and matching them against your garment data rather than guessing from a size label.

Pro Tip: Run a photography audit before you run a model audit. Most “AI accuracy” complaints trace back to inconsistent lighting or cropping in the source images, not the algorithm.

Testing, metrics and rollout phases for sizing systems

Test mapping logic and charts in staging, pilot on your highest-volume SKUs, and only expand once returns and conversion move in the right direction. Skipping the pilot phase is how a bad mapping rule reaches your entire catalogue in one deployment.

• Run unit tests against your mapping logic using known size conversions.
• Validate a sample of co-purchase or exchange data against the normalised output.
• Have a human reviewer sign off on normalised charts before publishing.
• Visually QA try-on renders across body types and garment categories.
• Run an end-to-end checkout test with the new charts live.

Watch five metrics through rollout: size-related return rate, the share of returns tagged as fit-related, try-on engagement rate, conversion by size band, and the size-swap rate on reorders. Poor fit accounts for the large majority of fashion returns, which makes the fit-related return share your clearest early signal of whether the new charts are working.

Roll out in three phases: pilot on one or two collections, scale to selected categories once metrics hold, then launch catalogue-wide. Set a rollback threshold in advance, such as a return-rate increase in the pilot group, rather than deciding on the fly.

Governance: roles, quality gates and catalogue hygiene

Assign clear ownership before you assign any tooling. A catalogue owner, a measurement steward, an imaging lead and a data engineer each need a defined role, or sizing accuracy quietly decays as new collections launch.

Recurring operational tasks:

• Periodic measurement audits against supplier tech packs
• Asset validation against your photography standard
• Metafield completeness checks before a collection goes live
• Documented exception handling for non-standard SKUs

Role Responsibility Catalogue owner Approves new size types and category mappings Measurement steward Verifies grading rules against supplier data Imaging lead Enforces photo standards for try-on eligibility Data engineer Maintains metafield definitions and lookup logic

Pro Tip: Run a monthly “catalogue sprint” where the team clears the backlog of missing measurements and re-maps new arrivals. It’s far cheaper than a quarterly clean-up after returns have already spiked.

What makes unisex sizing different from gender-specific sizing?

Gender-specific sizing typically starts from separate body proportion assumptions. Women’s charts commonly assume a defined waist-to-hip differential; men’s charts assume broader shoulder and chest proportions relative to waist. Unisex sizing collapses both into one scale, usually built around chest or body circumference and garment length rather than fitted shape.

That means a unisex size chart is closer to a single-axis measurement (a range of chest circumferences mapped to a label) than the two-axis logic of a fitted women’s garment. It works well for looser silhouettes: hoodies, oversized tees, straight-leg trousers. It works poorly for anything with waist shaping, structured tailoring or cup sizing, because those garments need dimensions a single-axis chart can’t express.

Standards bodies haven’t converged on one unisex numbering system the way they have for some gendered categories. Retailers effectively define their own unisex scale, then map competitor or supplier sizes onto it. That’s precisely why the normalisation work covered earlier matters more for unisex ranges than for gendered ones: there’s no external anchor to check your mapping against, so internal consistency is the only safeguard you have.

Practically, this means your unisex chart needs its own explicit gender value in the data model rather than being inferred as “the absence of men’s or women’s”. A product tagged unisex should carry unisex-specific measurement points, not a men’s chart relabelled at the last minute.

How should shoppers convert between men’s, women’s and unisex sizes?

The honest answer is that there’s no single universal conversion, because brands set their own numeric offsets. That’s exactly why your size-chart data needs to carry conversion logic rather than relying on generic advice to “size down” or “go up one”.

A reasonably reliable starting rule many retailers use: unisex sizing tends to run closer to men’s sizing in chest and body measurements, so a shopper typically buying a women’s size 12 might land closer to a unisex Medium or Small depending on the brand’s grading. But this only holds as a rough anchor, not a formula, because grading increments vary by category and by brand.

The practical fix at the data layer is a per-brand conversion table stored alongside your normalised size scale, mapping each brand’s unisex labels against equivalent men’s and women’s chest and waist measurements. This is where the category-first normalisation from earlier pays off directly: once tops, bottoms and shoes each have their own scale, converting between gendered and unisex labels within a category becomes a lookup rather than a guess.

For customer-facing guidance, the safest instruction is always to measure the body, not to convert from a previous size in a different brand or gender line. A tape-measure chest reading mapped against your normalised chart eliminates the conversion problem entirely, and it’s the same underlying data that powers automated size-recommendation tools. GarmCheck’s size-recommendation feature works from body measurements for this reason rather than asking a shopper what size they “usually wear” elsewhere.

Common challenges and limits of unisex sizing

The biggest limitation is structural: unisex sizing averages across two different typical body-shape distributions, so it fits the middle of both distributions reasonably well and fits the extremes of either distribution poorly. A retailer selling genuinely unisex product to a broad customer base should expect a wider natural return-rate baseline than a gender-specific line, simply because the chart is a compromise by design.

Category mismatch is the second major issue. Unisex sizing works acceptably for loose, non-fitted garments. It breaks down fast for anything with waist definition, cup sizing or fitted tailoring, where a single circumference measurement can’t capture the shape difference between bodies.

Long-tail SKU exceptions are a persistent operational drag rather than a one-time fix. Every new supplier or collection brings size strings that don’t map cleanly onto your existing scale, and without a maintained fallback hierarchy, these exceptions silently degrade chart accuracy over time.

There’s also a data-quality ceiling. Automated normalisation approaches, including the co-purchase matrix method Zalando researchers documented, depend on volume. A merchant with limited transaction history for a given category won’t get the same mapping accuracy a high-volume retailer achieves, and needs to lean more heavily on manual grading-rule definition instead.

Finally, unisex charts age. Grading rules that were accurate for one season’s fabric and cut don’t automatically transfer to a redesigned garment next season, which is why the governance checklist earlier treats measurement audits as recurring, not a one-off setup task.

Popular unisex sizing chart formats by apparel type

Tops (hoodies, tees, sweatshirts) typically use an alpha scale (XS to XXL) mapped against chest circumference and body length, since these garments are loose enough that a single circumference measurement captures fit reasonably well. Grading increments commonly run in five to seven centimetre steps per size, though this varies by brand and fabric weight.

Bottoms in unisex ranges tend to use either the alpha scale or a numeric waist measurement in inches or centimetres, depending on whether the garment is close fitting (joggers, fitted trousers) or loose (wide-leg, cargo styles). Fitted unisex bottoms are the category most likely to need a second measurement point, inseam alongside waist, because a single waist figure alone produces poor fit outcomes on tailored silhouettes.

Footwear uses the most standardised unisex format of the three categories, generally built around foot length in centimetres mapped to a shared numeric scale, sometimes with a small offset table for regional sizing conventions (US, UK, EU). Unisex trainers and boots are where cross-brand consistency is strongest, largely because foot length is a simpler, less shape-dependent measurement than chest or waist circumference.

Outerwear (jackets, coats) sits closer to the tops model but usually adds a sleeve-length grade, since layering assumptions differ more between bodies than torso circumference alone. Retailers offering unisex outerwear typically publish both a chest measurement and a sleeve length in the same chart, precisely because a single-axis scale understates fit variance on structured jackets.

What experienced merchants get wrong about unisex sizing

The most common error isn’t a bad mapping rule. It’s assuming your product images and metadata are ready for AI-driven fit tools when they’ve never been audited for that purpose. Retailers spend budget on the AI layer before checking whether the catalogue underneath can actually support it, which produces exactly the digitisation bottleneck this guide has flagged throughout.

• Hidden cost one: reworking inconsistent product images after launch costs more than a photography audit before launch.
• Hidden cost two: long-tail SKU exceptions eat developer time indefinitely if there’s no fallback hierarchy in the data model.
• Hidden cost three: hardcoded charts in theme templates mean every seasonal update needs a developer, which slows the whole catalogue down.

Quick wins worth taking in order: pilot on one collection, use rich-text metafields to launch fast, migrate to metaobjects once you’re managing shared charts at scale, and instrument your return-rate metrics from day one rather than adding them retroactively.

A short credibility note: none of this is theoretical friction. Every retailer that has tried to bolt AI fit tools onto an unstructured catalogue has hit the same wall, and it’s always the data, never the model, that causes the delay.

How GarmCheck fits into this blueprint

Once your size normalisation, metafield structure and product-truth layer are in place, GarmCheck plugs directly into that foundation. It’s a Shopify app or JavaScript snippet that generates a photorealistic fit render from a single customer photo in under ten seconds, and produces size recommendations from eight body measurements rather than a single guessed input.

The feature set matches the operational blueprint above rather than sitting apart from it: native Shopify or JS snippet integration, an eight-measurement size-recommendation engine, returns and conversion analytics tied back to your existing metrics, and demo fit bands you can show stakeholders before a full rollout. Because it reads your garment measurements and product-truth data directly, there’s no separate engineering build to make try-on work with the metafield structure you’ve already set up.

If your catalogue is normalised and your product-truth fields are populated, the next step is straightforward: try GarmCheck’s virtual try-on on a pilot collection and measure the fit-related return share before and after.

Sources

• How to add a size chart to a Shopify product page (with metafields)
• Building an AI virtual try-on workflow for fashion ecommerce: what happens beyond the model
• Size Chart Data Structure | HIT-AN Portfolio
• garment-measurements
• Size normalisation research (Zalando)

Recommended

• Plus size try-on for Shopify merchants: a practical guide — GarmCheck
• Denim fit guide for UK Shopify merchants — GarmCheck
• Body measurements from photo: a practical guide for UK fashion retailers — GarmCheck
• Server-side tracking for Shopify: a UK fashion brand guide — GarmCheck