Blink: a Tauri and React desktop client for Jellyfin

A community client, renamed on purpose

Blink is a modern desktop Jellyfin client made with Tauri and React, and the first thing in the README is a naming decision. JellyPlayer has been renamed to Blink to avoid confusion with first party Jellyfin apps.

That rename says a lot about the project's position. Jellyfin ships its own clients, and a third party project with a confusingly similar name creates support problems for both, so the author renamed rather than defended the name. The credits at the end of the README make the same point from the other direction, thanking all contributors of jellyfin-vue and acknowledging Jellyfin for creating the main service.

So this is a client for Jellyfin, not a fork of a Jellyfin client and not a server. It talks to a server you already run, and it is licensed under GPL-3.0.

The project is written in TypeScript, the default branch is main, and the last push was on 2026-10-15. The releases tell the maturity story plainly: v1.0.0-alpha03 from 2024-12-11, v1.0.0-alpha04 from 2026-02-08, and a nightly build tagged from February 2026. The version in the package manifest is 1.0.0-alpha.4, and the project is private on npm, so the builds come from GitHub releases rather than from a package registry.

The stack is Tauri 2, React and the official Jellyfin SDK

The dependency list is the most informative thing in the repository, and it describes a modern desktop application rather than a web page in a wrapper.

The shell is Tauri, with @tauri-apps/api at 2.10.1 and a set of plugins that tell you what the application actually does: the updater, the store for application state, the global shortcut plugin for a media player hotkey, the notification plugin, the dialog plugin, the clipboard manager, the process and shell plugins, the window state plugin so the window comes back where you left it, and an upload plugin. The plugin set is essentially a specification of what a desktop media client needs to do.

The user interface is React with MUI, at 7.3.7, plus @mui/lab, Emotion for styling, @popperjs/core, react-spring for animation, and a set of self hosted variable fonts, JetBrains Mono, Noto Sans, Plus Jakarta Sans and Space Grotesk, which is a considered typographic palette rather than a default.

The data layer is TanStack. React Query with its devtools for server state, React Router with its devtools, React Form, and React Virtual for long lists, which matters in a library view with tens of thousands of items. There is also @dnd-kit for drag and drop, which in a media client is how you reorder a queue.

And the API layer is @jellyfin/sdk at 0.13.0, the official Jellyfin SDK. That is a deliberate choice, and it is the right one for a third party client, because it means the client tracks the server's public interface rather than an undocumented one.

The feature list, and the two items that stand out

The features are listed in one block, and most of them are the obvious ones for a media client: play any media supported by the system, with DirectPlay for most files on Windows, macOS and Linux, a clean and minimal user interface, multi Jellyfin server support, cross platform, sorting and filtering of library items, and queue playback support.

Two are worth more attention.

The first is MediaInfo recognition, listed as Dolby Vision, Dolby Atoms, Dts, HDR10+ and more. The effect is that the client shows you the actual format of what is playing, which on a mixed library is the difference between knowing and guessing. It also means the client is reading the media, not just asking the server what it thinks.

The second is the intro skip button, which uses the jumoog/intro-skipper plugin. The interesting part is not the button but the dependency: rather than implementing detection itself, the client plugs in an existing plugin, which is the right shape for a feature that is hard and that other people are already working on. Media segment support is the other item in that family, an adoption of the segment format rather than a reinvention.

The screenshots in the README show the surfaces that matter for judging the work: the home screen, the library, a detailed music player, an item page, an album view, a search dialog and the video player, all at 2560x1600.

Building it needs Node, Rust and the C++ tools

The prerequisites are specific, which is normal for a Tauri application, because the Rust side compiles to a native binary and the frontend side is a web build.

The list is Node.js at 22.14.0, Rust at 1.85.0 or newer, the Visual Studio C++ build tools, and pnpm.

The three commands are short.

pnpm install
pnpm run tauri dev
pnpm run tauri build

The dev command runs the application with hot reloading, and the build command produces the distributable. Everything else lives in the scripts section of package.json, which the README points to rather than duplicating.

The package scripts show what the frontend half does on its own. The dev script is vite --force together with tsr watch, the latter being the TanStack Router generator, which regenerates the typed route tree when you add a route. The build is vite build, the preview is vite preview, and linting is Biome over the src directory with a fix variant, with a biome.json in the repository and a .prettierignore and .babelrc alongside for the older parts of the toolchain.

For a contributor the workflow is in the README's contribution section: check out the issues branch to see the features and bugs currently being worked on, add a feature or fix a bug, and create a pull request. The roadmap lives in a GitHub project rather than in a file, and there is a CHANGELOG.md in the repository.

Updates and application state are handled by Tauri's own plugins

The presence of a latest.json file at the repository root, next to the updater plugin and the store plugin, tells you how releases reach an installed client. That file is the updater's manifest, so a build can check a known location for a newer version and offer it, without the user hunting for a download page.

That is the whole update story in a desktop app, and it is worth contrasting with the alternative. A media client that cannot update itself is a client that quietly rots against a server whose API moves, and this one is built so that the update path is part of the platform rather than a script someone runs.

The other plugins fill in the parts a desktop media client needs and a browser tab cannot offer. The global shortcut plugin is for the play and pause key, the notification plugin is for now playing alerts, the window state plugin remembers the geometry of the window, the dialog plugin handles file pickers through the native dialog, the upload plugin is for anything the client needs to send, and the process and shell plugins cover launching the external player or the local media handling.

There is also renovate.json in the repository, so the dependency updates are automated, which for a project with this many packages is a practical necessity rather than a nicety.

Alpha releases, a nightly tag, and what the project asks of contributors

The release history is short and it is honest about the stage. v1.0.0-alpha03 came in December 2024, v1.0.0-alpha04 in February 2026, and there is a nightly tag built from a specific commit hash in the same month.

A nightly tag named after a commit is a useful convention. It means a tester can point at an exact revision, and it means the untagged branch head is not the only way to try something. For a client that talks to a server whose API is still moving, that is the difference between a bug report with a version and a bug report with a commit.

The contribution instructions are short and they point you at the issues branch first, which is where the in progress work is visible. That arrangement, a branch of work in progress rather than a tracker full of labels, works well for a small project with one main contributor, and the special thanks section names one other person who helped behind the scenes.

What the project does not have is any of the things that come with a long-lived release history, a compatibility matrix, or a stable channel. For a media client that is a trade rather than a flaw, because the alternative is a client that stops working with a server update and nobody maintaining it. The audience for an alpha is a user who knows that and is comfortable filing an issue when it breaks.

Editorial conclusion

Blink fits a Jellyfin user who wants a desktop client that plays files locally instead of transcoding, who wants the library metadata rendered with real format information, and who is willing to run an alpha build. It does not fit a household that needs a client with official support or a long release history, since the newest tagged release is an alpha from early 2026 and the nightlies are untagged builds of a moving branch. Verify three things before you install it: that the alpha you pick matches the Jellyfin server version you run, because the client uses the official SDK rather than a private API, that you understand the build is yours, since the contributor instructions ask you to open an issue and create a pull request rather than to hand you a binary, and what happens to your data, because the client is a third party and the privacy surface of a media client on your own network is not the same as the server's.

Frequently asked questions

Official sources

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