Jellyfin vs Plex

The feature lists are close enough to be useless. Both index a folder of video, both transcode, both do live TV and DVR, both have apps for the TV you already own. The decision underneath is what kind of object you want sitting in your rack.

Plex Media Server is a product. Someone else decides what it does, ships client apps for hardware you could never build for, and bills you for the privilege. Jellyfin is a program. It does what the code does, indefinitely, and nobody can renegotiate after you have moved 12 TB of video into it. Every argument below is downstream of that one difference.

What changed for Plex remote streaming, exactly#

Since 29 April 2025, remote playback of personal media requires that the server owner holds a Plex Pass, or that each remote viewer holds a Plex Pass or the cheaper Remote Watch Pass ($1.99/month, $19.99/year). "Remote" means not on the same network as the server, which includes the phone your partner is holding in a car park.

Enforcement arrived in stages. It began on Roku in late November 2025, and on 29 April 2026 it extended to Fire TV, Android TV, Apple TV, Samsung, LG, Vizio, PlayStation and Xbox. If your setup kept working through 2025, that is why, and it has now landed on the platform your relatives use.

Local-network playback stays free. Hardware transcoding has always been Plex Pass only. Put those two facts together and the current free Plex tier is a LAN-only, CPU-only server. The Pass itself went to $6.99/month, $69.99/year or $249.99 lifetime with the 2025 price increase. Along the way Plex retired the Plugins framework, Cloud Sync and Watch Later, so a few workflows people built in 2019 are simply gone.

Jellyfin has no equivalent line item because it has no line items. Remote access, transcoding, DVR, downloads and multiple users are all in the GPL-2.0 build.

What the spec table is actually telling you#

Skip the memory rows on your first pass. Both are one container with one SQLite database, both idle in the hundreds of megabytes, and both spend their real RAM on concurrent transcodes rather than on being awake. The two rows that decide anything are Licence and Identity.

Licence explains why one row can change next year and the other cannot. Identity explains the part people underestimate: Plex's none means accounts, sharing and login all route through plex.tv, and there is no way to point it at your own provider. Jellyfin's oidc-plugin is not much better in practice (the SSO plugin covers the web UI only, and native clients still hit Jellyfin's own user table), but the user database is a file on your disk either way. If you are building around a single sign-on setup, neither server is a good citizen, and Plex is not a citizen at all.

Which one your family will not complain about#

Plex, and Jellyfin users should stop pretending otherwise.

Plex's Apple TV, Roku and Tizen apps are better than Jellyfin's: faster to browse, more consistent about resuming, fewer subtitle surprises, better remote handling. That is what a decade of paid client development buys. Jellyfin's web client and Android TV app are genuinely good, the Kodi integration is excellent, and the iOS app has improved a lot, but Roku and older Samsung and LG sets are where Jellyfin still feels like a community project. Dolby Vision profile 7 and lossless TrueHD passthrough remain the two things that misbehave on specific TVs.

The honest test is not which app you prefer, it is who calls you when it breaks. If that is a parent, a partner who will not tolerate a second attempt, or a friend three time zones away, the polish is worth the subscription. If it is only you, and you watch on a browser, a phone or an Nvidia Shield, the gap is a rounding error you are paying $69.99 a year to close.

Which one transcodes 4K without a licence#

Both use the same underlying hardware paths: Intel Quick Sync, VAAPI on AMD, NVENC on Nvidia. The difference is the gate.

On Jellyfin, hardware transcoding is a configuration problem. Pass the device in and add the render group:

services:
  jellyfin:
    image: jellyfin/jellyfin:10.11.11
    devices:
      - /dev/dri:/dev/dri
    group_add:
      - "989"   # getent group render | cut -d: -f3
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /srv/media:/media:ro

Forget group_add and ffmpeg cannot open the device, falls back to software with no visible error, and you find out when the CPU pins during the first 4K HEVC stream. Check the playback info overlay: it says whether the session is hardware accelerated.

On Plex, the same --device /dev/dri:/dev/dri gets you nothing without an active Pass. The toggle in Settings, Transcoder is there, and it stays inert. This is the single clearest illustration of the difference between the two products: on one server the GPU you bought is yours to use, on the other it is a feature you rent. If you are still choosing hardware, GPUs, transcoding and local AI covers what an iGPU actually buys you in simultaneous streams.

What happens on upgrade day#

This is where Jellyfin gives back some of its advantage.

Plex upgrades are a tag pull. There is no supported schema downgrade, but breaking migrations are rare and the release cadence is steady, including security work: 1.43.3 on 1 September 2026 patched undisclosed flaws. The failure mode you should actually plan for is the library database itself, which corrupts often enough on large installs that Plex ships a repair procedure using its own bundled Plex SQLite binary rather than the system sqlite3.

Jellyfin's 10.11 (October 2025) was the hard one. It moved the library onto EF Core and merged library.db into a single jellyfin.db. The migration only runs from 10.10.7, runs once, has no downgrade path, and on libraries past roughly 50,000 items it can grind for hours with no visible progress. People who killed the container mid-migration lost watch history and metadata. Current stable is 10.11.11 (June 2026), and the next major skips 11 and goes straight to 12.0, in release candidates since June 2026 and at rc7 in August.

Two practical consequences. First, copy /config before any Jellyfin major, and let the first start run overnight if it needs to. Second, 10.11 dropped armhf entirely, so a Raspberry Pi on a 32-bit OS is stuck on 10.10.x and the fix is reinstalling 64-bit, not chasing a package. Either way, read An update strategy that does not lose data before you get into the habit of pulling latest.

Which one you can actually get your data out of#

Neither server stores anything precious in your media files. Watch history, play counts, users, collections and playlists exist only in the server database, and that is the asset.

Jellyfin: back up /config in full, or use the scheduled backup task added in 10.11 (Dashboard, Backups) which writes a consistent archive rather than a torn SQLite copy. /cache and the transcode temp are regenerable.

Plex: everything is under /config/Library/Application Support/Plex Media Server/, with the database at Plug-in Support/Databases/com.plexapp.plugins.library.db. Do not copy it while the server runs. Plex's own scheduled task keeps dated copies next to it, and those are your fastest restore.

The asymmetry is what you can do with the backup. A Jellyfin database is a SQLite file you can open, query and migrate. A Plex database is a SQLite file whose schema is undocumented and whose account bindings live in someone else's cloud. Moving off Plex is a migration project (Replace Plex walks it), and community tooling such as JellyPlex-Watched exists precisely because there is no supported export. Whichever you pick, fold the config directory into the routine described in Backups that actually restore.

Which one can change the deal after you have committed#

Only one of these can. Plex changed the remote-playback terms in 2025 for libraries that were already assembled, running and shared, and it phased enforcement in over eighteen months across platforms. That is not a criticism of the business decision, it is a description of the risk you accept: your server's behavior is partly a policy variable held by a company.

Jellyfin is GPL-2.0-only with no account, no telemetry gate and no licence check. The realistic risks there are different and worth naming: a volunteer client maintainer stops, a plugin you depend on gets archived (the OIDC plugin's original repository was archived in May 2026 and now lives in a community fork), or a major release migrates your database one way. Those are project risks. They are not someone changing your terms.

If you want the middle position, one payment and no cloud in the authentication path, that is Emby: see Jellyfin vs Emby.

The verdict, by situation#

What to do next#

Run both. One container each, different ports (8096 and 32400), pointed at the same read-only media directory. Give it a week on the actual televisions in your house, because the client experience is the only part of this comparison you cannot settle by reading.

While you are testing, wire up remote access properly rather than forwarding a port: Remote access without port forwarding and Reverse proxy and TLS cover the two normal answers. If you are assembling the wider stack around the server, Jellyseerr handles requests for either one, Sonarr and Radarr handle acquisition, and Stack planner will tell you what the whole thing costs in RAM before you build it. The rest of the category is in Media.