A VS Code colour scheme for JetBrains IDEs, and what it leaves out

The plugin is a colour scheme, and only a colour scheme

The VSCode Theme for Jetbrains IDEs is an IntelliJ platform plugin whose purpose is stated in its own marketplace description: it provides the Visual Studio Code editor colour scheme for JetBrains IDEs, with WebStorm, IntelliJ and Rider named among the many that are covered. The stated aim is to closely emulate the VS Code theme within the IDE, simplifying the process of switching between different development environments.

That last clause is the whole motivation. A developer who uses an IntelliJ based IDE at work and VS Code on a personal project spends time relearning what colours mean every time they switch, and the cost is small per switch but accumulates over a year. A plugin that aligns the two palettes removes that cost without changing either editor.

The implementation is an IntelliJ plugin written in Kotlin, built with Gradle. The repository has a `build.gradle.kts`, a `settings.gradle.kts`, the Kotlin source under `src/`, an `ide-clion/` directory, and a `readme/` directory for the marketplace listing. The plugin is published in the JetBrains Marketplace under id 19177, which is also the number in the version and download badges in the README.

The audience is narrow and clear: JetBrains users who want a VS Code look. The topics attached to the repository name the specific IDEs it targets, including Android Studio, CLion, PyCharm, Rider, WebStorm and GoLand.

Three themes, and the light one is experimental

The plugin registers three themes.

In the dark group there is VSCode Dark+, the classic Visual Studio Code dark palette, and VSCode Dark Modern, the newer default look of the VS Code editor. In the light group there is VSCode Light Modern, and the documentation marks it as experimental and invites bug reports through the GitHub issue tracker.

The experimental label is not a formality in a colour scheme. A colour scheme is not a list of hex codes that can be copied, it is a set of decisions about which token maps to which colour, and the mapping is constrained by what the IDE exposes. JetBrains plugins cannot set every colour the IDE uses, and the plugin's own note says that some text colours might not be accurate because JetBrains does not allow overriding those colours, or because the default colours are more intuitive.

For the best viewing experience the documentation recommends pairing the theme with the Rainbow Brackets plugin, which is a separate plugin that colours matching brackets. The pairing matters because bracket matching is one of the strongest visual cues in an editor, and the default JetBrains behaviour is a thin outline rather than the coloured brackets a VS Code user expects.

Syntax highlighting coverage is uneven across languages

The plugin documentation lists what it covers, and the split is informative.

Advanced syntax highlighting support is listed for JavaScript, TypeScript, Java, Dart and Flutter, Rust, Python, Kotlin, C# and F#, PHP and Go. C, C++ and Objective-C also appear in the advanced list, while basic syntax highlighting is listed for Ruby and many more.

Two things follow from that split. First, the languages with advanced support are the ones where a VS Code user would notice the difference most, because those are the languages with rich token hierarchies, where a keyword, a type, a function call and a property are all distinct colours in VS Code and would otherwise collapse into the JetBrains default scheme. Second, Ruby gets the basic treatment, which is close enough to be usable and further away to be visible if you sit in front of both editors all day.

Ruby is called out separately in the roadmap, which lists enhanced syntax highlighting for Ruby as an open item. That is a hint that the basic level is the current state rather than a permanent verdict.

The rest of the roadmap is a list of things a VS Code user would expect and a theme plugin mostly cannot deliver: file icons to match VS Code, rainbow brackets with three colours, and improvements to the light theme across all major programming languages. The file icons item in particular is a reminder that the plugin is working within the JetBrains colour scheme system, which covers text and some editor chrome, not the file explorer presentation.

Installing through the marketplace or from a release file

There are two installation paths, and the first is the ordinary one for a JetBrains plugin.

Using the built-in plugin system, the path is Settings or Preferences, then Plugins, then Marketplace, then search for "vscode theme", then Install Plugin. The plugin then appears in the theme selector of the IDE, and you pick the scheme you want from there.

The manual path exists for people who cannot reach the marketplace, which is a real situation on some managed workstations. The instruction is to download the latest release from the GitHub releases page and install it through Settings or Preferences, then Plugins, then the gear icon, then Install plugin from disk.

A reader setting this up should expect two things beyond the click-through. The first is that the plugin registers themes, so a search for "vscode" in the theme picker is how you find them after installation, not a settings entry of its own. The second is that the colour scheme applies to the editor, and the surrounding IDE interface, the panels, the tool windows and the menus, keep their JetBrains appearance.

For developers who want to change the source, the repository is a Gradle project with the `gradlew` and `gradlew.bat` wrappers at the root, so a local build is a wrapper invocation rather than a system Gradle install. There is a CHANGELOG.md at the top level and a `.run/` directory of run configurations, which is the JetBrains convention for sharing a run configuration with the team.

Release cadence and a single sponsor to keep it going

The version history is short and informative. Version 1.13.1 was published on 2026-10-16, version 1.12.0 on 2025-07-21 and version 1.11.1 on 2025-04-14. The repository's last push was on 2026-10-16, the same day as the latest release, so the project is not a one-off contribution but a maintained plugin with a recent update.

The gap between 1.12.0 in July 2025 and 1.13.1 in October 2026 suggests a low cadence, which is what you would expect from a plugin that follows the IDE's own release cycle. JetBrains plugins are versioned against the IDE platform they target, and a new IDE release means checking that the colour scheme still applies cleanly and that the theme keys have not moved.

The sponsorship situation is the thing to be aware of. The README asks for stars, plugin ratings, bug reports, pull requests against the roadmap items, and sponsorship, and the sponsorship line is repeated twice with a Buy Me a Coffee link. The phrasing of the request is that sponsoring helps ensure the project is actively maintained and improved.

For a plugin that a user installs once and forgets, the funding question is worth a moment of thought, because a colour scheme plugin with a single maintainer and a dependency on an IDE's internal theming APIs has a narrow window to fix breakage after an IDE update. The licence is BSD-2-Clause, which is permissive but still requires keeping the copyright notice.

When a colour scheme is the wrong answer

The most important limitation is not in the plugin, it is in what a plugin of this kind can be.

A JetBrains theme plugin controls colours, and colour is a small part of what makes an editor recognisable. The workbench layout, the file explorer, the panels, the keymap, the settings dialog and the debug view all stay JetBrains, because they are not themeable in the way the editor is. A developer who switches between VS Code and IntelliJ and finds the IDE still feels like IntelliJ will find this plugin helpful and incomplete at the same time.

There is a second practical limit. The plugin's own roadmap shows that the light theme is not yet at parity across languages, and that file icons and rainbow brackets are not part of the plugin. A VS Code user who works primarily in a light scheme, or in Ruby, or who relies on coloured brackets, is getting a partial port.

The genuine alternative is not another plugin but a different decision about the tools. A team that standardises on one editor removes the problem entirely, at the cost of a team member's preference and possibly of a feature their IDE has and the other does not. A team that cannot standardise can accept the small cost of two colour schemes and configure the VS Code side to match JetBrains instead, which inverts the problem but removes the dependency on a third party plugin staying current with the IDE.

For a developer who has already decided to keep both editors, this plugin is a reasonable answer, and a better one than trying to tune a JetBrains theme by hand until it resembles VS Code, which is a much larger job than it sounds.

Editorial conclusion

This plugin suits a developer who works in a JetBrains IDE and a VS Code setup in the same week and wants the syntax colours to match, especially one who already uses the Rainbow Brackets plugin. It is the wrong tool for anyone expecting the editor chrome, the file icons or the workbench layout to match, because those are separate roadmap items rather than shipped features. Check first which of the three themes the plugin registers in your IDE, since the light one is labelled experimental, and expect some text colours to stay as the IDE default because JetBrains does not allow plugins to override them.

Frequently asked questions

Official sources

1. dinbtechit/vscode-theme on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases