Sanity Pioneers: Get early access to betas, extra AI credits, and a direct line to the engineering team. Apply now

How to fix "Invalid Portable Text Editor value" for custom superscript decorator in production

3 repliesLast updated: Dec 2, 2025

I added superscript as a custom decorator to my block content editor. I did it with this code
marks: {
  // Decorators usually describe a single property – e.g. a typographic
  // preference or highlighting by editors.
  decorators: [
	{ title: 'Strong', value: 'strong' },
	{ title: 'Emphasis', value: 'em' },
	{ title: 'Code', value: 'code' },
    { title: 'Superscript', 
      value: 'sup', 
      component: (props) => (
        <sup>
          {props.children}
        </sup>
      ),
      icon: () => 'S' 
    },
  ],
When running sanity locally, my custom decorator displays in the block content editor. After pushing my code to production, my custom decorator for sup no longer display in the editor and I get an error "Invalid Portable Text Editor value" because it doesn't recognize "sup". What am I doing wrong? It says "Block with key 'dae3f4812ac2' contains marks (sup) not supported by the current content model.
AI Update

I can see what's happening here! The issue isn't with your decorator syntax - your code is actually correct. The problem is that you have existing content in production that contains sup marks, but your production Studio hasn't been updated with the schema that recognizes those marks.

What's Actually Going Wrong

When you developed locally, you:

When you deployed to production:

Your decorator syntax is fine - using component and icon at the root level is correct. The error message "Block with key 'dae3f4812ac2' contains marks (sup) not supported by the current content model" means the Studio schema doesn't match the content.

How to Fix It

Deploy your Studio to production:

sanity deploy

This will update your production Studio with the new schema that includes the sup decorator. Once deployed:

Why It Worked Locally

Your local development environment had the updated schema from the moment you added it, so there was never a mismatch between the content and the schema definition.

Frontend Rendering

Don't forget that when rendering this Portable Text on your frontend, you'll need to handle the sup decorator in your serializer:

const sup = (props) => <sup>{props.children}</sup>

<BlockContent
  blocks={yourContent}
  serializers={{marks: {sup}}}
/>

Or if you're using modern @portabletext/react:

import {PortableText} from '@portabletext/react'

const components = {
  marks: {
    sup: ({children}) => <sup>{children}</sup>
  }
}

<PortableText value={yourContent} components={components} />

The key takeaway: your decorator code is correct, you just need to deploy your Studio so production has the updated schema!

Show original thread
3 replies

Was this answer helpful?

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Related contributions