code-blocks adds syntax highlighting to Google Docs with an Apps Script add-on

A Docs add-on rather than a code editor

code-blocks is a syntax highlighting add-on for Google Docs, and the whole project is built around that constraint. The repository carries an appsscript.json manifest, a client/ directory and a server/ directory, plus a build.sh, a privacy-policy.md and a terms-of-service.md, which is the shape of a Google Workspace add-on rather than a standalone library. The add-on is listed on the Google Workspace Marketplace and the documentation walks through the three things a user does: starting the add-on, formatting inline code, and formatting code blocks. There is also a reformatting flow, for when code has already been highlighted and the highlighting no longer matches the edited source. So the user experience is that you select code in a document, open the add-on sidebar, and the formatting is applied. The audience is people writing technical documents in Docs, such as internal design documents, runbooks and teaching material, who want readable code without round-tripping through a code editor. What it is not is a code editor, and it does not try to be one.

Highlighting comes from highlight.js, so language support is inherited

The highlighting engine is highlight.js, and the limitation section of the documentation states the consequence plainly: Code Blocks is built with highlight.js and can only provide syntax highlighting for languages that are supported by that library. That single dependency shapes the whole feature. The package manifest pins highlight.js at 9.16.2 and adds highlightjs-graphql for GraphQL, so the language coverage is whatever that pair covers, and there is no mechanism in the add-on to add a grammar of its own. The documentation gives the escalation path for a missing language, pointing at the highlight.js page on requesting new languages. For an existing language that highlights incorrectly, the path is two steps. First check whether the latest release of highlight.js already includes the fix, and if it does, submit a pull request to this repository that bumps the highlight.js version in package.json. If highlight.js does not yet include the update, the request goes to their issue tracker. In other words, an unsupported language is an upstream request plus a version bump here.

Why highlighting cannot happen while you type

This is the most useful part of the documentation, because it explains a behaviour users would otherwise read as a bug. Code Blocks uses Google's Apps Script, a server-side JavaScript platform, to interact with Docs and format code. Each time the add-on formats a snippet, a request is made to the Apps Script backend to modify the current document. The documentation then lists four platform limitations that prevent formatting code as you type. The onEdit event that fires when a user modifies content is only available in Sheets, not in Docs. Time-driven triggers can only be used once per hour at most. Each request to modify the current document can take multiple seconds, so code formatting cannot be performed in real time. And the number of requests needed to update a document in near real time may exceed the service API quotas. The last point is the one to think about if you imagine a background formatter keeping a long document in sync. The architecture cannot do it, so every formatting action is an explicit user action.

Keyboard shortcuts only work while the sidebar has focus

The second platform limitation is about input. Keyboard shortcuts can only be handled by Code Blocks if the add-on sidebar is focused, which would require users to click the sidebar anyway. Keyboard events in the active document cannot currently be handled by Docs add-ons, and the documentation links the issue tracker entry for that. So the practical consequence is that the add-on cannot offer a shortcut like select code and press a key to highlight it, because the keystroke would go to the document rather than to the add-on. Anything the user types goes to Docs. The sidebar is the only place the add-on receives input, which shapes the interface design: you select the text in the document, then act in the sidebar. There is a related point about undoing the work. To clear formatting, you highlight the text and select Format, then Clear Formatting from the toolbar, with the keyboard shortcut Cmd and slash on OS X or Ctrl and slash on Windows. The documentation warns that this will not remove the table the text lives in if it is a code block, so you have to copy the text and paste it outside the table and then delete the table by right-clicking it.

The build pipeline is three scripts driven by build.sh

The repository builds three separate artefacts, and the scripts section of package.json names them. There is a build:gas target that runs ./build.sh gas, a build:js target that runs ./build.sh js, and a build:static target that runs ./build.sh static, with the overall build chaining all three. The devDependencies explain what each stage needs. @google/clasp is the command line tool that pushes and pulls the Apps Script project, browserify and uglifyify with uglify-es bundle the client JavaScript, clean-css-cli and juice handle the styles, and the build runs against Node 22.17.0 as the pinned engine. Deployment to Google is a separate step: the pushOnly script runs clasp push, and two convenience scripts chain a build with that push, one for JavaScript and one for the Apps Script code. A prepush hook cleans the dist directory and rebuilds everything. The result is that working on this add-on means having Node, clasp access to the Apps Script project, and an understanding that the server and client halves deploy separately.

What a version number does and does not tell you

The package version reads 1.4.3 while the repository has no GitHub releases, so the version is visible in the manifest but not published as a tagged artifact that a user can point at. The last push was on 2026-07-25, and the project is not archived. The licensing is MIT for the source, and the repository separately ships a privacy-policy.md and a terms-of-service.md, which is what a Marketplace add-on needs and which also tells you the project takes distribution terms seriously. The main upgrade risk for a user is not the add-on version but the highlight.js version behind it, since a new language or a fixed grammar only reaches users when the version in package.json is bumped and a new build is pushed. The practical maintenance question for anyone considering adoption is therefore not whether the add-on is maintained, but whether the language mix used in your documents is covered by the pinned highlight.js 9.16.2 release and the GraphQL add-on alongside it.

Editorial conclusion

Adopt code-blocks when your team writes and reviews code inside Google Docs and wants coloured, readable snippets without pasting from an external editor, and when a short pause while the format runs is acceptable. Do not adopt it if you need highlighting as you type, because the Apps Script backend cannot modify the document fast enough, or if your documents live outside the Workspace suite. Verify first that the language you need is covered by the highlight.js version the project depends on, that your document is not a code block table when you plan to clear formatting, and that you can work with the add-on sidebar as the only place keyboard shortcuts work.

Frequently asked questions

Official sources

1. alexwforsythe/code-blocks on GitHub
2. Issues
3. License: MIT
4. Project website
5. README