Adding simple formatting options in normal text fields in Sanity.io

5 replies
Last updated: Dec 7, 2021
Hi Sanity-Team and -Fans! I started with sanity a while ago for a big website with gatsby as the frontend and I'm loving it πŸ™‚ But I have one issue I can't solve. Hopefully you can point me into the right direction...

tl;dr ... is it possible to add simple formating-options in normal text-fields?
I use Portable Text for the main body of my pages and I've added a bunch of custom blocks to it for specific tasks. Like custom image/text-combinations or so. In Gatsby I use
block-content-to-react
to output those and it works like a charm.
But in some blocks I use just simple "text" fields when I need more space for userinput.

My client now asks if I can provide simple formating-options in those fields and I can't figure out how to do that without having to rebuild the whole structure and working with custom schemas and references (which would be a nightmare)

It doesn't have to be a whole new portable text/richtext field, but a simple textarea with bold, italc, link, headline-formats would be more then sufficient. I found the
markdown-input-plugin
(https://www.sanity.io/plugins/sanity-plugin-markdown ) and this could be an option. But maybe you know something more userfriendly? I could create a custom parser for it in my frontend to make ** -> strong etc.
Thanks in advance!
AI Update

I totally understand your situation! You want simple formatting in regular text fields without the complexity of full Portable Text blocks. Let me share some practical options:

The Short Answer: Yes, there are a few ways to add simple formatting to text fields, and you're on the right track with the markdown plugin!

Option 1: Use minimal Portable Text configuration

Instead of using the basic string type, you can use an array type with a stripped-down Portable Text configuration. This gives you a textarea-like field with just the formatting options you need:

{
  name: 'simpleText',
  type: 'array',
  of: [{
    type: 'block',
    styles: [{title: 'Normal', value: 'normal'}],
    lists: [],
    marks: {
      decorators: [
        {title: 'Bold', value: 'strong'},
        {title: 'Italic', value: 'em'}
      ],
      annotations: [
        {
          name: 'link',
          type: 'object',
          title: 'Link',
          fields: [{name: 'href', type: 'url'}]
        }
      ]
    }
  }]
}

This approach keeps you in the Portable Text ecosystem, so you can continue using block-content-to-react in Gatsby without additional parsing. You're just limiting which formatting options appear in the editor by customizing the styles, marks.decorators, and marks.annotations arrays.

Option 2: Markdown Plugin (Your Idea!)

The markdown plugin you found is definitely a solid choice! It's more user-friendly than raw markdown for many clients. You'd just need to add a markdown parser in your Gatsby frontend (like remark or marked) to convert it to HTML.

Option 3: Simple HTML in String Fields

Some folks allow basic HTML in string fields and sanitize it on the frontend, but this is generally not recommended as it's harder to validate and can be a security concern.

My Recommendation:

Go with Option 1 (minimal Portable Text config). Here's why:

  • No need to rebuild your structure - just change the field type from string to the array configuration above
  • Reuses your existing block-content-to-react setup in Gatsby
  • Gives clients a WYSIWYG experience
  • Keeps content structured and safe
  • Easy to extend later if needed

You can customize exactly which formatting options appear by adjusting what you include in the schema. Want to add headings? Add more items to the styles array. Need lists? Configure the lists array. This way, your clients get the simple formatting they need without the full complexity of your main body content blocks.

Hope this helps! πŸ™‚

Hey Christian! In your case, you would have to use a Portable Text field to give editors control over styles like that.
What most users do is to set up two separate versions of arrays of `blockContent`: one that has all of the bells and whistles for things like articles and one that only has a few fields for cases like you're describing.
Thanks! I thought it was not possible to use a Portable Text within another one. But I will try that πŸ˜ƒ
Crazy, it's easy peasy πŸ˜„ I looked for this a while now, but somehow I missed this solution πŸ˜„ Thanks again for pointing me into the right direction! πŸ‘
Crazy, it's easy peasy πŸ˜„ I looked for this a while now, but somehow I missed this solution πŸ˜„ Thanks again for pointing me into the right direction! πŸ‘
No problem – we should probably work on making this super evident.

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.

Was this answer helpful?