Jellyfin Quick Connect: sign in on your TV without typing a password

TL;DR

• Quick Connect signs a device in without a username or password typed on it. A code appears on the new device, and you approve it from a device that is already signed in.
• The Jellyfin Quick Connect documentation describes a two-device flow: the new device shows a code, an already signed-in device enters that code and confirms.
• In the server source, the code is 6 digits, generated with a cryptographic random number generator, and a pending request expires after 10 minutes (QuickConnectManager.cs).
• Quick Connect is on by default. An admin turns it off under Dashboard > General with "Enable Quick Connect on this server" (jellyfin-web strings).
• Not every client can do both halves of the exchange. The Jellyfin docs list which clients can sign in with a code and which can also approve one from another device.

What Quick Connect is

Typing a password on a TV remote, a set-top box, or any device without a real keyboard is slow and error-prone. Quick Connect exists to skip that step. The official documentation describes it plainly: "Quick Connect is a feature that allows users to sign in to clients without entering a username or password. Instead, a temporary Quick Connect code is generated and used to authorize login from an already authenticated client." The same page adds that this "streamlines the sign-in process, especially on devices with limited input options (like TVs or set-top boxes)."

The exchange always involves two devices. The docs call them Device A, "a new client where you want to log in," and Device B, "an already authenticated client (such as your browser, phone, etc.)." The new device never receives your password; it only receives a temporary authorization, in the same way a "sign in with this device" flow on a game console or a streaming stick works.

Turning it on (or off) on the server

Quick Connect ships enabled. The docs state: "By default, Quick Connect is enabled." To change that, an admin goes to the Dashboard, then the General tab, and unchecks "Enable Quick Connect on this server" (same source). That label matches the string key EnableQuickConnect in the jellyfin-web source, where it reads exactly "Enable Quick Connect on this server."

Clients can also check this setting themselves before offering the button: the Jellyfin API specification exposes GET /QuickConnect/Enabled, a public endpoint that returns whether the server currently allows Quick Connect at all. If it is off, jellyfin-web shows the string QuickConnectNotAvailable: "Ask your server administrator to enable Quick Connect."

Signing in on a TV, step by step

The steps below follow the official flow, applied to the case that started this article: a TV app with no keyboard, and a phone or laptop that is already signed in on the same server.

1. On the TV. Open the Jellyfin client and choose Quick Connect. The docs note that "on some clients, you will first need to press Manual Login; others may display the quick-connect code directly." A 6-character code appears on screen. Leave that screen open — the code disappears once it is used or once it expires.
2. On the already signed-in device. Open the client's settings and go to Quick Connect (in Jellyfin Web this sits under Settings). Enter the code from the TV and confirm.
3. Back on the TV. Once the code is confirmed, the TV signs in automatically. The documentation puts it simply: "If successful, Device A will be logged in automatically — no need to enter a username or password."

If you mistype the code, or if it has already expired, the docs describe exactly one outcome: "If the code is invalid or expired, you will see an error message and must try again." There is no partial state to recover from — starting over on the TV generates a fresh code.

Security and how long a code lives

Quick Connect trades a password for a short-lived, single-use code, so its safety depends on how that code is generated and how long it stays valid. The server's own source code answers both questions directly. In QuickConnectManager.cs:

• The code length is fixed at CodeLength = 6, generated as a 6-digit number using .NET's RandomNumberGenerator, a cryptographically secure source of randomness rather than a predictable counter.
• A pending request expires after Timeout = 10 minutes, with the file's own comment describing it as "the time (in minutes) that the quick connect token is valid."
• Once a request has been authorized, trying to authorize it again fails outright — the server throws an "already authorized" error rather than letting a code be reused.
• After a successful approval, the server deliberately keeps the request alive for one more minute so the waiting device has time to notice, per the code comment: it "can't expire immediately as otherwise some clients wouldn't ever see that they have been authenticated."
• Expired requests are swept out on the next request that touches Quick Connect, by comparing their age against the 10-minute timeout and removing anything older.

One thing worth naming plainly: this file contains no attempt counter, lockout, or rate limit of its own. What stands between a stranger guessing a code and access to the account is the size of the code space (900,000 possible 6-digit codes) and the 10-minute window in which a guess has to land — not a lockout after failed tries. That is a reasonable trade for a feature meant to save someone from typing a password on a remote, but it is also why Quick Connect approval should happen on a device you trust, and why leaving a stale code on screen for no reason is not a great habit.

Which clients support it

The documentation keeps a table of which official and community clients can do which half of the exchange: signing in with a code, and approving a code shown on another device. Quoted directly from the Jellyfin Quick Connect docs:

A pattern stands out: every TV-focused client in that list can sign in with a code but not approve one, which makes sense — approving a code means typing it in, and that is exactly the input a TV interface is worst at. The clients that can do both are the ones people also use on a phone or in a browser.

Swiftly Player is not part of that official table, so it is sourced separately here: its own code implements both directions. The sign-in side sits in Anmeldung.swift, which requests a code and polls until it is approved; the approval side sits in QuickConnect.swift, which submits a code shown on another device. This logic is shared across the iPhone, iPad, Mac and Apple TV apps and the Windows and Linux versions.

When it does not work

A few concrete, documented cases account for most Quick Connect trouble:

• Server has it disabled. If an admin unchecked "Enable Quick Connect on this server," every client should show a message to that effect rather than a working button; GET /QuickConnect/Enabled is what a well-behaved client checks first.
• Code expired or mistyped. Past the 10-minute window, or with a wrong digit, the server rejects the code and the docs' own guidance is to start over on the device that is trying to sign in.
• Hard-to-read code on some TV interfaces. A closed jellyfin-web issue reported that the Quick Connect code was rendered in a very small font on LG webOS TVs, making it hard to read from a normal sofa distance — a reminder that the same feature can look quite different depending on which client draws the code.
• Confusing errors on the server side. A closed core issue documented a ResourceNotFoundException surfacing during Quick Connect in an older release; it was addressed in that thread rather than being an ongoing, current problem.

FAQ

Summary

Quick Connect solves a real, narrow problem: getting a TV or set-top box signed in without a keyboard. The mechanism is simple by design — a random 6-digit code, a 10-minute window, and an already-authenticated device that vouches for the new one. Which clients can do which half of that exchange varies, and TV apps consistently land on the "sign in only" side of the table, for the obvious reason that they are bad at collecting the code the other way around. Swiftly Player implements both directions on iPhone, iPad, Mac, Windows and Linux, on top of the same server-side feature every other client relies on.