The standard WordPress Code block has historically been the “ugly duckling” of the block editor—essentially just a glorified <textarea> without any visual feedback. If you wanted syntax highlighting, you had to enqueue heavy libraries like Prism.js or Highlight.js, which often tanked performance scores. Consequently, most of us just settled for plain grey text.
WordPress.com recently dropped a significant overhaul that fundamentally changes how we handle snippets. It’s not just a facelift; it’s a refactor of the editing experience that introduces native syntax highlighting for over 100 languages. I’ve spent enough time debugging race conditions caused by third-party highlighter scripts to know that native support is a massive win for site stability.
Why Native Syntax Highlighting Matters
In the past, adding code meant choosing between a broken user experience or a heavy frontend payload. This update solves that by integrating the highlighting directly into the WordPress Code block. Furthermore, the new version includes several utility features that were previously “plugin-only” territory:
- Intelligent Drag-and-Drop: You can now drag a
.phpor.jsfile directly into the editor. It automatically converts to a code block with the correct language preset. - Visitor Utilities: Native “Copy” buttons and line numbers are now togglable settings in the sidebar.
- Semantic Styles: You can define syntax colors directly in the editor or via
theme.json.
Specifically, if you’re working on a developer-heavy site, this replaces the need for legacy plugins that haven’t been updated since the 4.x days. We’ve seen similar progress in smarter block management, but this is the first time the code block has felt like a professional tool.
Customizing the WordPress Code block via theme.json
One technical “gotcha” to note: while WordPress Core doesn’t yet support custom syntax colors in the global theme.json, the developers at WordPress.com have implemented a custom path for this. If you are building themes for that ecosystem, you can control the tokens using the settings.custom.core/code object.
Here is how you would define a custom color palette for your code snippets to match your brand identity:
{
"version": 3,
"settings": {
"custom": {
"core/code": {
"comment": "#94a3b8",
"keyword": "#8b5cf6",
"boolean": "#f59e0b",
"string": "#06b6d4",
"className": "#f97316"
}
}
}
}In contrast to traditional CSS overrides, this method ensures the editor and the frontend stay in sync. It’s much cleaner than writing specific selectors for .wp-block-code span. If you’re looking to dive deeper into how Gutenberg handles these global styles, check out my guide on typography management in theme.json.
A Note on Performance
I remember a client project where the “SyntaxHighlighter” plugin was adding nearly 400KB of assets to every page load, regardless of whether a code block existed. By moving this logic into the block itself, the assets are only loaded when needed. This is the “Architect’s” way to build—don’t load what you don’t use.
Look, if this WordPress Code block stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Pragmatic Takeaway
This update is a clear signal that the block editor is maturing into a developer-first environment. For more official details on the implementation, I recommend reading the official WordPress.com release and the Gutenberg theme.json handbook. Start purging those old syntax highlighting plugins today; your Core Web Vitals will thank you.
