The WordPress Code block has always been the ugly duckling of the block editor, a glorified <textarea> with no visual feedback at all. Syntax highlighting meant enqueuing something heavy like Prism.js or Highlight.js, which usually cost you a chunk of your performance score. So most of us shrugged and shipped grey text.
WordPress.com has now rebuilt the thing. The overhaul is not a coat of paint on the old block; the editing experience itself was rewritten, and it brings native syntax highlighting for more than 100 languages. Having spent plenty of evenings tracking down conflicts between third-party highlighter scripts, I will take native support over a plugin any day.
Why native highlighting matters
Until now, putting code on a page meant picking between an unreadable snippet and a heavier frontend payload. Highlighting inside the WordPress Code block removes that choice. The new version also picks up a few things that used to require a plugin:
- Drag a
.phpor.jsfile straight into the editor and it becomes a code block with the language preset already set. - Copy buttons and line numbers are native now, toggled from the sidebar.
- Syntax colors can be set in the editor or in
theme.json.
On a developer-heavy site this replaces the legacy plugins that have not seen an update since the 4.x days. Block management has been getting better for a while, as I noted in smarter block management, but this is the first time the code block has felt like a tool rather than a placeholder.
Customizing the WordPress Code block via theme.json
One gotcha. WordPress Core does not support custom syntax colors in the global theme.json yet, so the WordPress.com developers wired up their own path for it. If you build themes for that ecosystem, the tokens live under the settings.custom.core/code object.
A custom palette for your snippets, matched to your brand colors, looks like this:
{
"version": 3,
"settings": {
"custom": {
"core/code": {
"comment": "#94a3b8",
"keyword": "#8b5cf6",
"boolean": "#f59e0b",
"string": "#06b6d4",
"className": "#f97316"
}
}
}
}Unlike a pile of CSS overrides, this keeps the editor and the frontend in sync, and it beats writing selectors against .wp-block-code span. I went through how Gutenberg handles global styles in typography management in theme.json.
A note on performance
I once inherited a client project where the SyntaxHighlighter plugin shipped close to 400KB of assets on every page load, code block or not. With the logic inside the block, those assets load only where a snippet exists. That is the difference worth caring about here.
If WordPress Code block work like this is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
What to do with it
The block editor keeps picking up things developers actually asked for, and this is one of them. The official WordPress.com release has the implementation detail, and the Gutenberg theme.json handbook covers the settings side. If you still have an old highlighting plugin active, this is a good week to remove it.
