Scyfin: a modern CSS theme for the Jellyfin web client

A theme that is one @import line, not a plugin

Scyfin is a modern CSS theme for the Jellyfin web UI, with support for backdrops and custom accent colours. The repository itself is tiny, and the top level entries give that away: a CSS directory, the LICENSE, the README and an images folder. The primary language is CSS, and there is no build step, no package.json, no compiled artefact.

That is a deliberate and unusual shape for a theme. Most theming systems for an application like Jellyfin ship a plugin, a build pipeline and a bundle of hashed assets. Scyfin does none of that. It publishes plain CSS files, and you add them to your server by pasting an @import url into the custom CSS field that Jellyfin already exposes.

The base theme for Jellyfin 10.11.X and above is:

@import url('https://cdn.jsdelivr.net/gh/loof2736/scyfin@latest/CSS/scyfin-theme.css');

Everything else in the project follows that pattern. The files are served from jsDelivr, the CDN for GitHub repositories, using the repository path and a tag. There is no Jellyfin plugin to install, nothing to restart, and nothing on the server that knows your theme exists beyond the CSS string you pasted into a settings field.

That trade is worth naming plainly. You get an install that takes seconds and survives a Jellyfin upgrade in the sense that nothing is overwritten. You also give up any guarantee that the theme keeps working, because the stylesheet is written against the client markup rather than against a stable public API.

The version split is the first thing to get right

There are two base themes, and choosing the wrong one is the most likely reason a Scyfin install looks broken.

For Jellyfin 10.11.X and above, the import uses the @latest tag:

@import url('https://cdn.jsdelivr.net/gh/loof2736/scyfin@latest/CSS/scyfin-theme.css');

For Jellyfin 10.10.X and lower, the documentation tells you to use the @v1.4 tag instead:

@import url('https://cdn.jsdelivr.net/gh/loof2736/[email protected]/CSS/scyfin-theme.css');

And it adds a note that you should replace the @latest tag with @1.4 for any options you use with this version. That is a specific warning about the option sheets, not only the base sheet, which means the older Jellyfin line is supported, but at a frozen point in the project's history rather than at its head.

The maintenance reality matches that. The recent releases are Scyfin v1.5.10 on 2026-10-10, v1.5.9 on 2026-10-08 and v1.5.8 on 2026-10-04, three releases in one week, and the last push was on 2026-10-10. So the head of the project is moving quickly, and the older tag is the escape hatch for anyone still on an older client.

For a self hosted server, that matters. The Jellyfin version is whatever you last upgraded to, and the theme you get depends on a tag in a URL, so the version boundary is a real decision rather than a detail.

Two install paths that will fight each other if you mix them

Jellyfin exposes custom CSS at two levels, and Scyfin documents both, along with a warning about combining them.

The server-wide install goes through the admin dashboard. You click the hamburger icon in the top left, navigate to Dashboard, and if you do not see it you need to be signed in to your admin account. From there you navigate to Branding, find Custom CSS code near the bottom, and paste the @import url for the base Scyfin theme. Any option or theme imports go in the same field. You then click Save.

The single client install goes through the user settings instead. Click the hamburger icon, navigate to Settings, then Display, and find Custom CSS code near the middle. The same @import url for the base theme goes there, optionally followed by any option or theme imports, and then Save.

The warning attached to the client install is the important part. If there is any server-wide custom CSS, you may want to enable Disable server-provided custom CSS code, because the two themes will interfere with each other. The wording is deliberately strong, and the mechanism is obvious once you think about it. Both sheets are loaded into the same document, both target the same class names, and CSS has no way to arbitrate between them beyond source order.

So the practical rule is to pick one level. Server-wide if you want every user of the server to see the theme, client-level if you want it for yourself on one browser. Doing both means one of them wins, and you will not necessarily know which.

Options and colour variants are separate imports, not settings

Everything else is layered as additional imports below the base theme, which means the whole configuration lives as a stack of CSS files in one text field.

There are three documented options. The first disables the static left drawer, so the navigation panel stops being permanently pinned open. The second disables backdrops on navigation pages, which turns off the blurred artwork background on every page except the media details page, with the note that backdrops must be enabled in the client settings for this to have anything to disable. The third changes the search results in the Identify menu from a grid to a list, which the documentation recommends for identifying items with long names.

On top of that sit four colour variants: Seafoam, Coral, Snow and OLED, each imported as its own stylesheet.

The layer ordering matters, and the documentation is explicit that these go below the base theme. A colour variant that sets accent colours has to win over the base sheet, and a layout option that changes the drawer's display has to win over the base layout, so the import order in the field is doing real work rather than being cosmetic.

The OLED variant is the one worth a second look for anyone running a media server on a television. The readme ships separate screenshots for the OLED theme on the homepage and the details page, which suggests a dark treatment intended for OLED panels where an unlit pixel is genuinely black.

What breaks when Jellyfin changes its markup

The fragility is structural, and it deserves to be said plainly rather than as a caveat at the end.

Scyfin is a stylesheet that targets the DOM classes the Jellyfin web client emits. It has no access to a supported API for theming, no plugin registration, and no version negotiation beyond the two tags the documentation tells you to choose between. When Jellyfin's client changes the class names or the structure of a page, the selectors in the theme stop matching and the affected rules simply stop applying.

The symptom is not a crash. It is a UI that looks half themed, with one element still in the stock style and another in the theme's style, on a page that was designed to be internally consistent. That is harder to diagnose than a failure, because nothing reports an error.

The workaround is also already in the documentation, and it is the @v1.4 tag. If the current theme stops matching after a Jellyfin update, pin the older tag until the project catches up. The project released three versions in the week before its last push, which is a good sign that someone is watching the client, but it is also an indication that the theme is being adjusted frequently to follow it.

The @latest tag has a second implication that is easy to miss. Because jsDelivr resolves the tag at request time, the CSS your server serves can change without you doing anything, and your server's appearance can change after a Jellyfin upgrade that had nothing to do with the theme. That is convenient during development and undesirable in production, which is an argument for pinning a version tag rather than tracking latest.

Against a Jellyfin plugin theme, and against the stock client

Two comparisons clarify the choice.

The first is against a Jellyfin plugin theme, which is the alternative most people consider first. A plugin ships inside Jellyfin's plugin system, is versioned against the client, and can be enabled or disabled from the dashboard. It can also do things a stylesheet cannot, such as adding its own settings page or server-side behaviour, and it can be shipped to users who never paste anything into a settings field.

Scyfin takes the opposite approach on every one of those points. Nothing is installed, nothing is versioned against the client, the configuration lives in a text field, and the user has to paste an import. What Scyfin gains is that it cannot break the server, it survives a Jellyfin upgrade untouched, and applying it takes one paste rather than a plugin upload. It also means that distributing the theme to other users of your server, if you run a shared instance, is a manual operation rather than a plugin install.

The second comparison is against leaving the stock client alone. The stock client is what Jellyfin ships, it is what the documentation describes, and it is what your users already know. The reason to override it is aesthetic, and Scyfin's feature set is entirely in that direction: a modern look, accent colours, backdrop handling, a less intrusive drawer, a list view for long search results. None of it adds capability.

So the decision is not about capability at all. It is whether you want your server's appearance to differ from the default enough to accept the maintenance coupling that comes with it.

Editorial conclusion

Adopt Scyfin if you run your own Jellyfin server and want a different look for the web client without installing anything on the server. Skip it if you need a themed native app, since this is a web client stylesheet, and be careful if you must pin a version, because the CSS is served from a CDN tag rather than shipped with the client. Verify first which Jellyfin version you run, because the base theme targets 10.11.X and above while 10.10.X and lower need the older tag, and confirm whether you already use server-wide custom CSS that would collide with a client-level install.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. loof2736/scyfin on GitHub
4. README
5. Releases