React Syntax Highlighter: Prism and highlight.js for React

Why React Syntax Highlighter Uses Syntax Trees

React Syntax Highlighter addresses a specific React problem: displaying highlighted source code without replacing the entire code block through `dangerouslySetInnerHTML` or direct DOM manipulation. The README says the component uses a syntax tree to build the virtual DOM. React can therefore update the DOM elements that actually change when code or styling changes, rather than treating every update as a complete HTML replacement.

That distinction matters for applications built around function components and declarative rendering. The highlighted output remains a set of React elements instead of an opaque HTML string. It also gives callers access to line-oriented props such as `lineProps`, `lineNumberStyle`, and `wrapLines`, features that are awkward to retain when a highlighter only returns markup.

The package targets React rather than React Native. Its README points React Native users to `react-native-syntax-highlighter`, so adopting the web package in a native interface would cross an explicitly documented boundary. The default branch is `master`, the repository is not archived, and the last push was on 2026-10-08. That is current repository activity, but the README does not define a support policy or promise of ongoing compatibility with future React releases.

Prism, highlight.js, and the Rendering Pipeline

React Syntax Highlighter supports two syntax ecosystems. The main package is used with highlight.js-oriented styles, while `react-syntax-highlighter/prism` is used with Prism styles. The package dependencies include `highlight.js`, `highlightjs-vue`, `lowlight`, `prismjs`, and `refractor`. The project description identifies this as React highlighting based on Prism or highlight.js AST output, and the README credits `lowlight` and `refractor`.

The important design choice is that token information becomes React output. A caller supplies the source through `children`, identifies the grammar through `language`, and supplies a style object through `style`. When `useInlineStyles` remains at its default value of `true`, the component applies style objects to highlighted elements. This avoids requiring a separate stylesheet merely to obtain the default appearance. The available languages are separated into `AVAILABLE_LANGUAGES_HLJS.MD` and `AVAILABLE_LANGUAGES_PRISM.MD`, so an engine-specific import must be matched to its grammar list.

Passing plain text as `language` renders monospaced text without language-specific highlighting, according to the README. This can be useful when the input is log output or a language for which no grammar has been selected. It also means that `language` is not merely documentation metadata. Selecting an unavailable or mismatched language definition changes what the component can recognize.

The package exposes both CommonJS and ES module entry points. `package.json` lists `dist/cjs/index.js` as `main` and `dist/esm/index.js` as `module`, while also declaring `sideEffects` as `false`. These packaging details indicate that consumers can select module formats through their build tooling and that bundlers may remove the module when none of its exports are used.

Installing the npm Package and Adding TypeScript Types

The documented npm installation adds the package as a runtime dependency:

npm install react-syntax-highlighter --save

The package contains JavaScript source rather than bundled TypeScript declarations. The README recommends installing the separately maintained type module when TypeScript or ESLint needs those declarations:

npm install --save-dev @types/react-syntax-highlighter

For pnpm projects, the README gives these installation commands:

pnpm add -D react-syntax-highlighter
pnpm add -D @types/react-syntax-highlighter

The pnpm form installs both packages with the `-D` flag exactly as documented. That is worth noticing because the npm example saves the main package normally but installs its types as a development dependency. The repository also includes a `package-lock.json`, but the README does not give a lockfile installation tutorial, so the available instructions stop at package installation.

Rendering JavaScript with an Inline Highlight.js Style

A first component can follow the README example. It imports the main component, selects the `docco` style from the highlight.js style directory, sets `language` to `javascript`, and places the code string in the component children.

import SyntaxHighlighter from 'react-syntax-highlighter';
import { docco } from 'react-syntax-highlighter/dist/esm/styles/hljs';
const Component = () => {
  const codeString = '(num) => num + 1';
  return (
    <SyntaxHighlighter language="javascript" style={docco}>
      {codeString}
    </SyntaxHighlighter>
  );
};

The reader should see the short arrow function rendered with the colors assigned by the `docco` style. This is a real use rather than merely installing the dependency: the `language` prop selects the grammar, and `style` supplies the visual mapping.

The README states that a default style is used when the selected style is not included. That fallback reduces the cost of omitting `style`, but it also means that `style` is operationally relevant. Projects with strict visual requirements should confirm that their intended style exists in the matching `AVAILABLE_STYLES_HLJS.MD` or `AVAILABLE_STYLES_PRISM.MD` list. Import paths differ by ecosystem, so replacing the highlight.js path with a Prism path without changing the package entry point would not be a documented configuration.

Inline Styles Versus CSS-Controlled Output

Inline styling is the default because the package supplies JavaScript-based style objects and does not require another library's stylesheet. Consumers can pass `customStyle` to merge settings into the outer `pre` tag, with later values overriding earlier ones. Props intended for the direct `code` tag can be supplied through `codeTagProps`, and arbitrary props are spread onto the outer `pre` element.

Projects with an existing CSS pipeline have a different route. Setting `useInlineStyles` to `false` suppresses style objects and adds class names to highlighted elements. The README then directs users to one of the CSS files supplied by highlight.js. This is useful when themes must be managed by CSS tooling, but it transfers responsibility for loading the stylesheet and ensuring that its selectors cover the selected language tokens.

The choice affects application architecture. Inline styles keep the theme in the JavaScript dependency graph and work without an additional CSS include. CSS classes support external theme switching and browser inspection, but require a separate stylesheet and matching token classes. The README does not document a theme schema shared by all Prism and highlight.js styles, so a theme should not be assumed to transfer unchanged between the two engines.

Line Numbers, Wrapping, and Custom Render Boundaries

Line presentation is configurable at several levels. `showLineNumbers` adds numbers beside the code. `startingLineNumber` changes their first value when line numbering is enabled, while `lineNumberStyle` accepts either a style object or a function receiving the current line number. `lineNumberContainerStyle` overrides the container's default placement and padding.

`wrapLines` defaults to `false`. Once enabled, each code line receives a wrapping element, and `lineProps` can provide an object or a function of the line number. That creates a concrete reason to enable wrapping: callers cannot perform line-level actions when the component does not create line-level elements. `wrapLongLines` separately controls the `code` element's `white-space` behavior, choosing between `pre-wrap` and `pre` as documented.

Virtualized rendering introduces another constraint. `showInlineLineNumbers` is intended for use together with `showLineNumbers` when numbers must appear correctly in renderers such as `react-syntax-highlighter-virtualized-renderer`. The component also accepts `renderer`, `PreTag`, and `CodeTag` for custom output boundaries. These hooks can support a different DOM structure, but they increase integration work because the replacement components must behave as expected by the supplied renderer.

The README does not provide performance limits, recommended maximum code-block size, or benchmarks for updating a changing code string. Consequently, the AST and virtual-DOM design should not be treated as proof that every large input updates cheaply. Virtualization is mentioned through an external renderer rather than enabled by a documented prop on the base package.

Release Cadence, Dependencies, and MIT Licensing

The repository has releases at `v16.1.0`, `v16.1.1`, and `v16.1.2`, dated 2025-10-28, 2026-02-26, and 2026-10-08 respectively. The repository is not archived, and its last push was on 2026-10-08. This establishes recent changes, but the README does not document a long-term support policy, upgrade window, or compatibility matrix.

An upgrade can affect more than the React wrapper. The declared runtime dependencies include version ranges for `highlight.js`, `lowlight`, `prismjs`, `refractor`, `@babel/runtime`, and `highlightjs-vue`. Consumers should therefore review changes across the wrapper and whichever highlighting stack they import. The separately installed `@types/react-syntax-highlighter` can also need attention in TypeScript projects because it is not bundled into the package.

The repository is licensed under the MIT License. That permits use, modification, distribution, and sublicensing under the license's conditions, but this article does not interpret whether a particular distribution satisfies notice or attribution obligations. Projects should read the repository's `LICENSE` file for the exact terms. React Syntax Highlighter also references Prism and highlight.js, whose own licenses and bundled assets remain separate considerations when the package is redistributed.

Editorial conclusion

React Syntax Highlighter is a practical choice for React applications that need Prism or highlight.js output while retaining React elements, inline styles, CSS-class support, or custom rendering. It is less suitable for React Native, where the documentation directs users to react-native-syntax-highlighter, or for projects committed to a particular external highlighting runtime with different AST and styling APIs. Before adoption, verify the language definition and style file for the required engine, decide between inline styles and classes, and confirm that React rendering remains acceptable for the expected code size. For React Native, use react-native-syntax-highlighter rather than this package.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-syntax-highlighter/react-syntax-highlighter on GitHub
4. README
5. Releases