Burp Customizer: FlatLaf themes for Burp Suite, with the mismatched pixels and all

The extension works by hijacking Burp's Look and Feel

Burp Suite 2020.12 replaced the old Look and Feel classes with FlatLaf, an open source Look and Feel class which also supports third party themes developed for the IntelliJ Platform. Burp Customizer is the extension that takes advantage of that switch: it lets you use those IntelliJ themes inside Burp Suite and includes a number of bundled themes to try.

The history explains why it exists at all. The README's opening is a joke about hackers only working at night, so people asked PortSwigger for a dark theme for years, and when the dark theme finally arrived some people wanted more. The result is a theme picker with a large catalogue attached.

The catalogue is large indeed. The images section in the README shows Atom One Dark and Dark Purple each rendered in the Burp Customizer, Repeater and Logger views, and a cell announcing 56 more themes. The screenshots name two specific Burp panels, Repeater and Logger, that the theme is trying to blend.

The project is a Java Gradle build, licensed AGPL-3.0, with the source under src/, a build.gradle, a settings.gradle, the gradlew wrapper, and BappDescription.html and BappManifest.bmf for BApp Store metadata. The BApp files are what let the extension be listed in Burp's own extension marketplace.

Custom GUI elements are the hard part, and the README admits it

The Limitations section is the most useful part of the documentation, and it is unusually direct.

The explanation is that Burp uses a number of custom GUI elements, and PortSwigger extended the default Look and Feel classes with a number of additional properties. The author's approach was to try to find standard elements whose colours could be used to replace the custom properties. Some themes might not have those properties, or might not fit the theme perfectly. If any elements do not fit, the request is to open an issue on GitHub with the theme name and a screenshot.

That is the whole limitation in one paragraph, and it is a structural one rather than a bug. FlatLaf themes describe a standard component set, and Burp adds proprietary components on top. The extension maps what it can from the standard palette and leaves the rest to the theme's own defaults, which means the result is a good approximation rather than a guarantee.

The request for screenshots with theme names is also telling you how the remaining gaps get fixed. A theme that lacks a property cannot be fixed by the extension alone, because the missing colour has to come from the theme, so the workflow is to report the theme and let the theme author add the property.

There is a bundled extra that goes further than the others. Carbonfox is described as a very dark theme based on the carbonfox palette, and it includes Burp's HTTP message editor colours, row highlights and a red Intercept on button, which are exactly the elements that generic themes tend to miss.

Installation is a jar dropped into Burp

Installing the extension takes two steps. Download the latest jar from the GitHub releases page, then add the jar to Burp Suite.

The jar is loaded as a Burp extension, which is the mechanism Burp provides for third party code. That means the extension runs inside the Burp process, and it also means Burp has to be a version that loads extensions of this kind, which the README states explicitly: it supports Burp Suite 2026.x, both Community and Professional.

The maintenance story is one of the better parts of the project. The build is tested weekly against the latest Burp Suite Community release, which is a concrete answer to the question that matters most for an extension, which is whether it still works with the current product. A weekly test against the real application catches a Burp update that broke the extension before most users do.

The release history shows the same commitment with a gap. v1.0.4, tagged as v2024.10 Support, came out on 2024-12-17, and before that v1.0.3 in June 2021 and v1.0.2 in February 2021. The last push was on 2026-10-06, so work is happening well after the 2024 release, and the repository is not archived.

The version tag naming is a small detail that carries information. Naming a release after the Burp version it supports, rather than after the extension version alone, tells you the compatibility target at a glance.

Usage depends on setting the base theme first

The usage sequence is three steps and the order matters more than it looks.

First, select the correct base theme from Burp's User options and Display menu, in order to set the correct icon pack. Second, choose a theme from within the Burp Customizer tab. Third, if you like the project, give the repository a star.

The first step is the one people skip. The icon pack is chosen by Burp based on its own base theme, so if you pick a light IntelliJ theme in the customizer while Burp is still set to its dark base, you get mismatched icons, which is precisely the kind of visual inconsistency this whole project exists to remove. The base theme and the custom theme are two different settings, and they have to agree.

The theme choice itself is made in a tab inside Burp, not in a separate preferences dialog, which is the convenient part. Because the choice happens in a tab inside Burp, switching themes takes place in the same window you are already working in.

The two future plans in the README point at where the current implementation stops. They are to allow loading from.theme.json files, and to allow manual specification of additional defaults and overrides. The first is about importing your own theme rather than only choosing from the bundled set, and the second is about overriding the defaults by hand, which is the escape hatch for the mismatched element problem described in the limitations.

Building and testing against a real Burp jar

The build section covers the case where you want to build from source, for tweaking or for development. You clone the repo, build the jar with ./gradlew jar, and add the built jar at ./releases/BurpCustomizer.jar to Burp Suite.

The test setup is the more interesting part. To check every theme against your Burp version, you run the tests with a Burp jar: ./gradlew test -PburpJar=/path/to/burpsuite.jar. Without that property, the Burp specific tests are skipped.

So the test suite has two modes. Without a Burp jar it runs the parts that do not need the real application, and with one it runs the theme rendering checks against that exact Burp build. That is how the weekly compatibility test works, and it is also how you would check a theme you are contributing against the version you actually use.

The project structure supports that arrangement. There is a .run/ directory, which is the IntelliJ IDEA run configuration format, so the project expects to be opened in that IDE, and the gradle/ directory plus the wrapper scripts mean the build itself does not need a Gradle installation.

One note on the licence. AGPL-3.0 is a copyleft licence with the network use clause, which is a serious consideration if you plan to modify the extension and run a modified copy on a shared service, and a lighter one if you only install the published jar.

What the theme actually changes

It is worth being concrete about scope, because the word theme covers more than colours.

The extension replaces the Look and Feel, so it changes the widget rendering: the fonts, the borders, the selection colours, the scrollbars, the general chrome of the Swing interface. It also reaches into the areas the README singles out. Carbonfox is the bundled example that includes the HTTP message editor colours, the row highlights, and a red Intercept on button, and the screenshots show the Repeater and Logger panels rendered in the applied theme, which is the demonstration that the panels themselves are picking up the theme rather than just the frame around them.

What it does not do is change how Burp behaves. No functionality is added by the extension, no request handling changes, and the intercept logic is unaffected. This is a presentation layer tool, and it is valuable for exactly that reason, because it is a small, understandable change to a product you rely on rather than a fork you maintain.

The comparison worth naming is a full manual theme override inside Burp itself, which is what some people do with Swing look and feel settings and custom UI defaults. That route works without an extension, but it is per-machine configuration that you have to repeat, that nobody else gets, and that does not survive a Burp update. The extension makes the same result shareable, which is the difference in approach.

Editorial conclusion

Adopt Burp Customizer if you work in Burp Suite and want a different look and feel than the stock dark theme, especially if you already work with IntelliJ Platform editors and want the same palette in both. Do not adopt it expecting a pixel perfect result, because Burp uses custom GUI elements whose colours the extension can only approximate, and some themes simply lack the properties needed. Before you install, set the base theme in Burp's User options and Display menu first, since the icon pack depends on it, and note that the jar is licensed AGPL-3.0 if you intend to modify and redistribute it.

Frequently asked questions

Official sources

1. C0DEbrained/BurpCustomizer on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases