Syntax Highlight matches files by UTI, and macOS decides which formats it is allowed to claim

The extension only appears after you launch the app once

Installation is not the last step, and the documentation is emphatic about it in two places. After installing, the application has to be launched at least once so the system can detect the Quick Look extension, and the same instruction appears again where the extension is enabled, with the explanation that this is how macOS discovers the extension at all. Once it has been seen, the extension becomes available under System preferences, then Extensions, then Quick Look, where it still has to be switched on. The main window also checks for updates automatically when it is launched, so the first launch does two jobs: it registers the extension and it looks for a newer build. A user who copies the app into Applications and then opens a source file will see nothing until that sequence is complete.

Files are matched by type identifier, not by extension

The format handling is built on the Uniform Type Identifier rather than on the file name extension, and that choice explains most of the app's behaviour. A UTI definition carries both a list of extensions and the associated MIME types, so a type can claim several extensions at once. Some types are declared by the system itself, while others are registered by whichever application owns the format, which means one extension can map to several UTIs depending on what else is installed. Two extensions called the same thing can therefore mean different things to the system on two different machines. Rather than pick one, the application registers support for many UTIs, including ones that look redundant, so that a file is still recognised on a Mac where a different application claimed the type.

macOS hands out format permissions one release at a time

There is a version by version list of what the system allows an application to manage, and it explains several gaps in the supported formats. On Catalina, which is macOS 10.15, a set of formats cannot be managed at all, and the examples given include xml, plist, html, ts, dart, txt and common images such as jpg, gif and png. Big Sur, macOS 11, added plist back to the list of manageable formats. Monterey, macOS 12, added xml. The pattern is that the app's own list cannot be ahead of the operating system, so a format appears in the documentation when the OS first permits it. The app targets macOS 12 and later, and for macOS 11 and 10.15 the newest compatible release is 2.1.30.

Dart is listed and then marked as unhandleable

Some entries in the format list carry a rendering instruction instead of a language name, and those are the interesting cases. Several formats are highlighted as XML, including Adobe Acrobat sequence files, Flex files, configuration profiles, designspace files and the two ePub container formats. Others are treated as a different language entirely: a CocoaPods spec is highlighted as Ruby, a Babashka file as Clojure, an environment file as INI, an Azkaban flow as YAML, an Astro file as JSX and a CUDA file as C++. AppleScript files are handled differently again, automatically decompiled with osadecompile before being highlighted. Dart appears in the list as Dart source files and is immediately marked as reserved by macOS and unable to be handled, which is the format permission problem from the previous section applied to one specific language.

One universal binary, three processes and an XPC service

The repository layout shows how the app is split. There is an Application directory for the main program, a QLExtension directory for the Quick Look piece that Finder talks to, and an XPCService directory for work that must not run in the extension's own process, with a matching SyntaxHighlightRenderXPC directory and a named entitlements file for the render process. A highlight-wrapper directory sits next to them, which is where the Highlight engine from the upstream project is invoked rather than reimplemented. The released application is compiled as a universal binary covering Intel and Apple silicon, so a single download covers both architectures. Alongside those are a ShortcutCommand directory for the macOS Shortcuts entry point, a Tests directory, a settings_chk directory, a support_files.xcfilelist used by the build, and a dos2unix directory for line ending handling.

Three install routes, and only one of them compiles anything

There are three ways in, and their costs differ. The precompiled route is to take the app from the releases page and move it into the Applications folder; that build is the codesigned and notarized one, which is what makes it the route with the fewest surprises on a locked down Mac. The Homebrew route is a single command:

brew install syntax-highlight

The third route is building from source, and it has one extra step that is easy to miss: the clone is not usable as it stands, because the Highlight engine arrives as a submodule and has to be initialised and updated before the project will build.

git submodule init

git submodule update

Build numbers 79 to 81, and a command line tool in the tree

The release numbering shows a project that ships often in small steps. Version 2.1.30, build 79, is dated 2026-04-14, then 2.1.31, build 80, on 2026-09-15 and 2.1.32, build 81, the next day, with the last commit on the default branch landing on 2026-09-16. The gap between 79 and 80 is five months and the gap between 80 and 81 is one day, so the cadence is not fixed. Two directories in the tree sit outside the extension itself and are worth knowing about: a syntax_highlight_cli directory, so the same highlighting can be driven from a terminal, and a settings_chk directory, which suggests a separate check over a settings file. There is also a TODO.md, a CHANGELOG.md, and a docs site generated from index.md with a _config.yml. The distribution statement is short: the application is offered in the hope that it will be useful, but without any warranty.

Editorial conclusion

Syntax Highlight fits someone who wants to read code in Finder without opening an editor, on a Mac running macOS 12 or later, and who is willing to launch the app once so the system registers the extension. It does not fit older systems without dropping back to version 2.1.30, and formats the operating system reserves stay unreachable no matter which version you install. Before installing, check which macOS release you are on, note that the precompiled build is the codesigned and notarized one, and expect to enable the extension by hand in Extensions rather than having it appear immediately.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sbarex/SourceCodeSyntaxHighlight on GitHub