Learn Shiki Rehype Pretty Code - Inline Code Highlighting
Episode 9 of 23

Learn Shiki Rehype Pretty Code - Inline Code Highlighting

You will enable highlighting for inline code via the bypassInlineCode option, write a language meta inside inline code, then match its color semantics with the surrounding code blocks so the article looks consistent.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

Up to this point, highlighting only applies to fenced code blocks. Yet articles are full of inline code: function names, variables, CLI flags, or properties written inside a sentence. Without special handling, inline code appears plain with a single default color.

Episode 9 covers inline code highlighting: the bypassInlineCode option, how to mark the language on inline code with meta, styling the result in CSS, and a strategy for matching inline color semantics with related code blocks. By the end of the episode, you can write a sentence mentioning fetch and make that token appear with the correct color right away.

Enabling Inline Highlighting

The bypassInlineCode Option

By default, rehype-pretty-code only processes fenced code blocks and leaves inline code as is. To turn on inline highlighting, set the bypassInlineCode option to false in the plugin configuration:

JSEnable inline highlighting
import rehypePrettyCode from "rehype-pretty-code";
 
const options = {
  theme: "github-dark-default",
  bypassInlineCode: false,
};

A value of false on bypassInlineCode makes the plugin process inline <code> elements inside paragraphs as well. After this, inline code without a language meta is still highlighted using a guessed language or defaultLang.

Wiring the Option into the Pipeline

Combine that option into the unified pipeline as usual:

JSPipeline with the inline option
unified()
  .use(remarkParse)
  .use(remarkRehype)
  .use(rehypePrettyCode, {
    theme: "github-dark-default",
    bypassInlineCode: false,
  })
  .use(rehypeStringify);

Make sure the plugin order is correct: rehype-pretty-code must be installed before rehypeStringify. Once the pipeline is ready, rewrite your documents and check the result in the browser.

Marking the Language on Inline Code

The Meta Syntax Inside Backticks

Without a language marker, Shiki guesses the inline language based on context and the result can be wrong. To be sure, write the language meta right after the code inside the backticks, like map in the following example:

map transforms an array one by one, and proses calls a custom function.

That short explanation ensures the map token is colored as a JavaScript keyword and proses as a function. The way to write it is directly on the same line as the sentence, without a fenced code block.

Why Language Markers Matter

Without a marker, a word like name could be colored as a property, variable, or string depending on Shiki's guess. With an explicit marker, inline colors are consistent with the surrounding code blocks that use the same language. This also keeps the render result deterministic when you switch themes.

Styling Inline Code in CSS

Targeting Already-Highlighted Elements

After bypassInlineCode: false, tokens inside inline code are wrapped in spans with the same classes as in code blocks. You can target the code element for background and radius:

Style inline code
[data-rehype-pretty-code-title] + pre code,
p code {
  background: rgba(110, 118, 129, 0.2);
  border-radius: 6px;
  padding: 0.2em 0.4em;
}

The p code rule gives a soft background to inline code inside paragraphs, while the tokens inside remain colored according to the theme. Small padding makes the highlight look like a marker without disrupting the text flow.

Letting Token Colors Dominate

Don't override the foreground color on the code element because that will erase the highlighting. Let the token spans decide the color, and limit your styling to background, border, and radius. This principle is the same as code blocks: structure from CSS, colors from the theme.

Matching Color Semantics

Consistent Language in One Discussion

When a paragraph discusses one function, use the same language for inline code and nearby code blocks. If the block uses TypeScript, write String.raw in the sentence, not String.raw. This consistency keeps readers from hesitating when reading tokens.

Avoiding Page-Level Inconsistencies

Review the whole page after rendering to find inline code whose colors look wrong due to a mistaken language guess. Look for tokens with suspicious colors and add a language marker. This step is quick and makes the final result look professional.

A Complete Application Example

Here's the final pipeline with inline highlighting active along with the theme and defaultLang:

JSComplete configuration
import rehypePrettyCode from "rehype-pretty-code";
 
const options = {
  theme: "github-dark-default",
  defaultLang: "plaintext",
  bypassInlineCode: false,
};

With defaultLang: "plaintext", inline code without a language marker isn't colored at all, so tokens with explicit markers stand out more. You can change this value to suit your writing style.

Conclusion

Key takeaways:

  • Inline code is only highlighted when bypassInlineCode is set to false.
  • Inline code language is marked with meta inside the backticks, e.g., proses.
  • Inline tokens use the same classes as code block tokens.
  • Inline styling is limited to background and radius, not token colors.
  • Consistent language keeps inline colors aligned with related blocks.
  • defaultLang controls inline code without a language marker.

In episode 10 you'll learn Shiki transformers: using the @shikijs/transformers package like transformerNotationDiff and transformerNotationHighlight, and creating custom transformers to add or change tokens and metadata of the highlighting result.

Learn Shiki Rehype Pretty Code - Inline Code Highlighting | Learn Shiki Rehype Pretty Code