# KefinTweaks and the Jellyfin plugin that refuses to wait for upstream > KefinTweaks is a collection of JavaScript enhancements for the Jellyfin web client, including a watchlist, a customizable home screen, an improved search and an appearance manager, and its author says he hopes most of it becomes obsolete when Jellyfin ships the same features natively. The project is pre-1.0 and expects bugs. **ranaldsgift/KefinTweaks** — An essential collection of Jellyfin Tweaks that you always knew you needed - Repository: https://github.com/ranaldsgift/KefinTweaks - Stars: 738 · Forks: 24 - Language: JavaScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/ranaldsgift-kefintweaks ## A plugin built out of unfulfilled feature requests KefinTweaks is described as a comprehensive collection of enhancements and customizations for Jellyfin, focused on, but not limited to, filling gaps in functionality based on the community's most desired feature requests, with a link to the Jellyfin feature request site filtered by most wanted. That framing is the whole thesis of the project, and it is unusual for a plugin to state it this way. The named features are a watchlist, a customizable home screen, an improved search experience and an appearance manager, referred to as a skin manager. The plugin does not compete with Jellyfin's own roadmap; it implements the parts of that roadmap that have not arrived yet, and the author is explicit about the endgame. He says that in the future he hopes the majority of this plugin will become obsolete, as many of these changes get implemented and included in the native Jellyfin experience, as the community has so long desired. That is a coherent position for a community plugin, and it also tells you what you are installing: a temporary layer whose individual pieces are each waiting to be upstreamed or, in some cases, waiting to be abandoned. The origin story is equally direct. The author started working on these scripts to meet his own personal needs in August 2025, noticed a lot of overlap between the functionality he wanted and what the community was requesting, and decided to share it. The scope has grown and changed drastically since, from a small set of tweaks for his own server into a larger feature set. One dependency is worth knowing about up front. The slideshow at the top of the home screen shown in the project's video is not part of KefinTweaks, it comes from the MediaBar plugin by other authors, which is a hint that this plugin composes with others in the same ecosystem rather than trying to do everything. ## It works by injecting JavaScript into the web client The repository layout is the clearest description of the mechanism, and it differs from a normal Jellyfin plugin. There is no `package.json` and no `build` directory, no manifest, and no compiled output. What is there is `injector.js`, `kefinTweaks-plugin.js`, `kefinTweaks.minimal.js` and `kefinTweaks-default-config.js`, plus directories for `configuration/`, `helpers/`, `pages/`, `scripts/`, `skins/` and `tests/`. The names imply the approach. The plugin code is loaded into the browser and patches the Jellyfin web client from the outside, rather than registering through a documented extension point in the server. That is why there is an `injector.js` separate from the plugin itself, and why the file names distinguish a full version, a minimal version and a default config. The `pages/` directory is where the user-facing pieces live, and the repository also ships a `skins/` directory, which holds the appearance manager's assets. The `scripts/` and `helpers/` directories hold the JavaScript, `configuration/` holds configuration, and `tests/` is present at the root, so there is a place for automated checks even if the README does not describe them. The `scripts/` and `pages/` naming is a hint about the design: the enhancement is a set of page-level pieces rather than a rewrite of the client. Installation is handled in the readme's own Installation section, which the table of contents splits into Prerequisites and Setup Instructions, and the configuration that results from it lives in the `configuration/` directory with a default file at the root. The `kefinTweaks.minimal.js` file suggests a lighter variant that a user can choose when the full set is more than they need. None of this is described as a documented extension API, and that is the important observation for anyone planning to rely on it. The plugin's stability is tied to the internal structure of the Jellyfin web client, which changes when Jellyfin changes. ## The client versions it advertises, and the devices it targets The badges at the top of the readme carry real information that is easy to miss under the logo. The Jellyfin version badges point at three release lines, with the version numbers 12.0, 11.0 and 10.0, each linking to a specific release page. So the project advertises support across three major Jellyfin versions rather than only the newest one, which matters a great deal for a self hosted server, because upgrading your media server is a decision with a maintenance cost and users are often months behind on it. The device badges are longer: Windows, macOS, iOS, Android, a browser, LG WebOS and Xbox. That list is the meaningful one, because it tells you the plugin is not confined to a desktop browser. The same JavaScript that patches the web client runs in a TV client, in a mobile app and on a console. Any injection based approach has to survive being loaded in all of those, and the browser and TV cases in particular have different performance and lifecycle characteristics from a desktop tab. A jsDelivr hits badge suggests the plugin is also served from a CDN, and the README carries a link to a Discord channel dedicated to KefinTweaks inside the Jellyfin community server. For a plugin this young, that community channel is likely to be the fastest route to an answer about a specific installation problem. The overall picture is a plugin written for the whole range of Jellyfin clients rather than for one, and the number of environments it claims to cover is also the number of environments in which an injector can fail in a different way. ## A watchlist, and the pages built around it The table of contents in the readme lists the feature set in detail, and the watchlist is the largest section of it, broken into its own pages. The watchlist section covers a watchlist page, a series progress page, a movie history page, a user statistics page, and an export and import capability. The existence of a per-user statistics page and an export/import pair is the interesting part. A watchlist that only holds items is a list; a watchlist that tracks how far through a series you are, records what you have watched, and can be exported and reimported is a data store, and a data store has a migration story that a simple list does not. Export and import also implies a format that someone else might have to read, and the readme does not describe the format. That is worth noting for anyone planning to keep their data across a reinstall of the plugin, because an undocumented format is a compatibility risk of its own. The rest of the contents list continues into an enhanced home section and beyond, cut off in the visible readme, along with sections on data caching and a community requests progress tracker that lists feature requests completed and feature requests planned. That progress tracker is a nice piece of design for a plugin like this. Because the project is explicitly a bet on features not yet in upstream, a public list of what it has covered and what it intends to cover is the thing that lets a user decide whether to install it at all, and the fact that there is a planned column rather than only a done column is an honest signal about the direction of travel. ## Data caching is the mechanism underneath the faster screens The contents list has a Data Caching section as a top level entry, separate from the features themselves, which tells you caching is treated as infrastructure rather than as one more tweak. The reasoning is not spelled out in the visible documentation, so it has to be inferred from the structure rather than read. In a client-side plugin that adds new screens, the default behaviour is to re-request the data each time a view mounts, and on a media server with a large library, where a single user library can hold thousands of items, that is the difference between a page that appears immediately and a page that appears after a round trip. A cache in front of the new pages is what makes the added features feel native rather than bolted on, which is the standard the author set himself when he said the goal is to complement and enhance the native Jellyfin experience in a way that feels like it is native functionality. The same applies to the search improvement. Search over a large library is the operation most worth caching, and most likely to be slow without it. The risk of a cache is staleness, and in a media server the obvious case is content changing underneath the client: a new episode added, a watched status changed on another device, a library refresh. A cached view that is not invalidated correctly shows the wrong thing, and on a home server where several family members watch on different devices, an out of date watchlist or progress page is a visible annoyance rather than a technical detail. The readme does not describe the invalidation strategy, so the practical advice is to check the behaviour when your library updates rather than to assume it. ## The pre-1.0 caveat is in the readme, and it should be in your decision The author puts a caveat about maturity in his own words, and it belongs in any evaluation of this project. Before the 1.0 release, he says, you can expect to potentially encounter some issues or bugs. He adds that he tries to address them as quickly as he can, and he appreciates the time spent raising issues in the first place. The release history is consistent with that. There are three recent releases and they are close together: v0.5.0.1 on 2026-10-18, v0.5.1 on 2026-10-18, and v0.5.2 on 2026-10-19. The last push to the branch was on 2026-10-19. This is a project in active development, at a version below one, shipping several builds a day. That has a double edge. A plugin that changes often fixes problems quickly, and the author is clearly responsive. But the combination of a pre-1.0 version number, a fast release cadence and a mechanism that patches the web client from the outside means a change in Jellyfin itself can break your installation without warning, and the fix will come as a plugin update rather than as a coordinated release. The second practical point is the licensing of the code, which is MIT, so modification and redistribution are permitted with attribution. That is a real convenience for anyone who wants to adjust the appearance manager or the home screen layout and keep the change. The third is scope. The project is a plugin for a self hosted media server, and the person who operates that server is the one who installs it. Unlike a server side plugin, this one changes what every client sees, including clients on televisions and phones that the operator does not control. ## Against waiting for upstream, the difference is who does the work The alternative to installing this is waiting for Jellyfin to implement the features natively, or using a separate companion service for the one thing you actually miss. The difference in approach is about who absorbs the work and who carries the risk. Waiting for upstream means the work is done once, by people who can change the client properly, with no injection layer to maintain and no version compatibility matrix to track. The features arrive, eventually, in the form the project intended, and there is nothing for you to install. The cost is time, and for a watchlist that means months or years of no watchlist. A companion application means you keep the server stock and add one more thing to run, with one more set of credentials and one more thing to update. KefinTweaks sits in between, and its positioning is the interesting part. The author is explicit that he wants the majority of the plugin to become obsolete as the features land upstream, which means the plugin is designed to be retired piece by piece rather than to become a permanent layer. That is a healthier expectation than a plugin whose author intends to maintain a parallel fork of the client forever. There is also a scope question this plugin answers that the alternatives do not. A watchlist with progress tracking and per user statistics is not a media server feature, it is a personal media tracker, and the author says these scripts began as things he needed for his own server. That is a good sign for the fit, because the features are shaped by actual use rather than by a feature request vote, and it is also a caveat, because a personal server is a single user, whereas a shared family server has several users with different habits and the statistics and history pages are exactly the features where that difference shows. ## Conclusion KefinTweaks fits a self hosted Jellyfin user who wants a watchlist and a home screen they can rearrange without waiting for the upstream project to build them, and who is comfortable with a pre-1.0 plugin that injects itself into the web client. It is the wrong choice for a server operator who wants a supported extension point, and for anyone who needs stability, because the author states that bugs before 1.0 should be expected. Before installing, verify three things: that your Jellyfin version is one of the ones the project advertises support for, that the config file you are handed is the one you intend to run, and how the injector behaves across a client update, since the plugin works by patching the web interface rather than through a documented extension API. The code is MIT licensed, the current release is v0.5.2 from 2026-10-19, and the last push was on the same day. ## FAQ ### What is KefinTweaks and what does it add to Jellyfin? It is a collection of JavaScript enhancements for the Jellyfin web client, focused on filling gaps in functionality based on the community's most wanted feature requests. Named features include a watchlist with progress, history and per user statistics pages, a customizable home screen, an improved search experience and an appearance manager. ### How does KefinTweaks work with the Jellyfin web client? The repository contains `injector.js`, `kefinTweaks-plugin.js`, `kefinTweaks.minimal.js` and `kefinTweaks-default-config.js` alongside `pages/`, `scripts/`, `helpers/`, `configuration/`, `skins/` and `tests/` directories, with no package manifest or compiled build output. The plugin works by injecting JavaScript into the web client rather than through a documented server side extension point. ### Which Jellyfin versions and devices does KefinTweaks support? The badges in the readme point at Jellyfin version lines 12.0, 11.0 and 10.0, and the device badges cover Windows, macOS, iOS, Android, a browser, LG WebOS and Xbox. There is a dedicated KefinTweaks channel in the Jellyfin community Discord server for support. ### Is KefinTweaks stable enough to install? The author states that before the 1.0 release you can expect to potentially encounter some issues or bugs, and the recent release history shows v0.5.0.1 and v0.5.1 on 2026-10-18 with v0.5.2 on 2026-10-19. The code is MIT licensed. ## Sources - [Issues](https://github.com/ranaldsgift/KefinTweaks/issues) - [License: MIT](https://github.com/ranaldsgift/KefinTweaks/blob/main/LICENSE) - [ranaldsgift/KefinTweaks on GitHub](https://github.com/ranaldsgift/KefinTweaks) - [README](https://github.com/ranaldsgift/KefinTweaks/blob/main/README.md) - [Releases](https://github.com/ranaldsgift/KefinTweaks/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ranaldsgift-kefintweaks