Generate a QR code for a user to scan to connect to a server without emby connect

[displayname0504 21]

It'd be great if server admins could generate a QR code for a user to scan with their app to connect to a server, without using EmbyConnect.

[Luke 42420]

HI, yes this is something that we'd like to do. Thanks.

[julianb 39]

This would be great! Would make the setup much easier

[Outbound 1]

Bump, 

Any movement on this?

[Luke 42420]

Hi, yes this is something we’re planning to do. Thanks.

[visproduction 352]

QR code creation works already for any Internet address.  Aim it at the IP address or domain if you have SSL setup.  Users with browser saved passwords can just automatically log in to the home screen.  It works for web browser and mobile now.  What else do you need?  Did you want Emby to do the QR code creation?  Why?  It's easy to do that with all sorts of custom images inserted online.  I don't understand. What you are asking to be a new feature?

Edited February 26 by visproduction

[Nanganator 8]

On 25/02/2026 at 17:13, visproduction said:

QR code creation works already for any Internet address.  Aim it at the IP address or domain if you have SSL setup.  Users with browser saved passwords can just automatically log in to the home screen.  It works for web browser and mobile now.  What else do you need?  Did you want Emby to do the QR code creation?  Why?  It's easy to do that with all sorts of custom images inserted online.  I don't understand. What you are asking to be a new feature?

I read the OP's request as more about making it easier for users of apps to sign in, not to direct someone to a web page (which as you rightly point out can already easily be done hence why I don't believe it is OP's request).

Unless your emby url is https://a.at it is a PITA to have to use the TV remote to type in the URL, username and password, especially if you're using minimum complexity and length rules for passwords. Would love a QR code on the TV to sign in. FireTV has the remote keyboard option which is nicer than TV remote (FireTV in general is though). But something ala Apple TV would be great where you can just scan the QR code via the emby app on an already signed in device and the TV is connected to your emby instance and signed into your account.

Similarly, to sign into the app on a phone/tablet, having a per user QR code at the bottom of the "App Settings" page would make it easier.

[visproduction 352]

Aha, I see  a QR code solution inside the TV app or somehow using a QR code to get the TV app to go to your IP or SSL domain for Emby.  Going through mobile would be a good step.  Is it possible to use a mobile QR and send that to an Emby TV App?  Hmmm how would the TV get that message?  Can the TV get incoming commands and then ask what app you want to use to open the URL?  Then just point to Emby and maybe that can work.  I don't access to any of this hardware.  Please post here if there is a way.  I would like to see that.

[ebr 16416]

We are tossing around design ideas on this type of thing right now.  Can't promise any time table yet but we are in process.

[Nanganator 8]

3 hours ago, visproduction said:

Aha, I see  a QR code solution inside the TV app or somehow using a QR code to get the TV app to go to your IP or SSL domain for Emby.  Going through mobile would be a good step.  Is it possible to use a mobile QR and send that to an Emby TV App?  Hmmm how would the TV get that message?  Can the TV get incoming commands and then ask what app you want to use to open the URL?  Then just point to Emby and maybe that can work.  I don't access to any of this hardware.  Please post here if there is a way.  I would like to see that.

Exactly!! Avoid having to bang in your (in my case loooong) public Emby domain and username/password.

Based on my very limited knowledge of session auth, I believe the QR sign in would still rely on "Emby Connect" in some way. You'd need a central server somewhere which can be used to facilitate the connection between the TV and the mobile device because UPnP is not reliable (or secure) enough to work consistently and CGNAT exists. When you select the new "Sign-in with mobile device" option on the TV, the TV would make an outgoing connection to the (hard coded) Emby Connect server and generates a unique, but short lived, session token to be used in the QR code. The TV would then poll the server for a short period for a response. In parallel, when you scan the QR code with an authenticated (logged in) Emby app on a mobile device, the mobile device also connects to the central server and drops a short lived auth token of the logged in user for the TV to then pickup (through the polling) and signs in to your personal Emby instance. Ideally there would be some kind of "Confirmation" code shown on both devices which requires confirming the codes matches to prevent MitM before the auth token is sent/received.

Now of course you may get people who will be unhappy that this won't facilitate "special situations" like where users have TV's in restricted VLAN's with no/limited internet access etc. and/or only want a LAN connection to a local Emby instance using a class c IP or mdns domains, but that is more of a power user scenario who is likely capable enough of just logging in to their TV/app manually.

[visproduction 352]

Nan,

I don't think Emby Connect is a solution, because each server connection is private and Emby is not going to want a keep track of any record of those IP or domain names.  That's part of the whole concept behind Emby.  For mobile or Web it's already a pretty easy fix.  Just have any web address page that you have control and put whatever QR code or link, whichever you like on the page. The page can be hidden, the link can be also hidden inside an image area section.... whatever.  That takes care of Web and mobile.  Users just go to the bookmark page, click and you are in.  It's easy to do as a web admin.  You can even just email people the QR code.  Trying to add this to Emby does not seem like  good use of development time, plus it would have to be updated and bug checked. Really not worth doing.  Mobile and web is alread covered.

It's back to the TV apps, Firestick and Google TV, Roku... how can those be automated with a QR code?  Well that's tricky.  You want that the user does NOT have to enter in either an IP address or a domain name, once, on their App and never have to do it again.  Imagine that the budget to add in some QR code step to all Emby's apps, test for bugs, review the code and try the feature on say 20 different setups, then release with an update in a guide and then some follow up questions and answers in the forum.  Suppose the cost of that is, say 20 hours dev time plus an extra 6 hours every year to troubleshoot and respond to forum questions.    Say that totals to $1500  and every year around an extra $300 support time.  Do you think that is a good feature to green light and write a check to pay for it?  How many people would like th QR code ,instead of just entering the IP or URL address?  Isn't access pretty straight foward now.  If enterting he IP address or domain name isn't working, doesn't that mean something else is wrong with the server setup?  In that case a QR code would also fail, exactly like the IP or URL entry.  I don't see how having a QR code fixes anything, other than not having to type in a number or name. How is it possibly worth making a feature that needs additional support when the QR can't really be set to solve anything other than not having to type something in?  Am I missing something?

 

[Nanganator 8]

OK, a lot to unpack here so apologies that this will be lengthy.

For the sake of clarity when I refer to "Emby Connect" I am referring to the general central infra the dev team has together which all internet connected personal Emby instances already report in to. So does not need to be the pre existing "Emby Connect" service if we're being overly literal. But token exchange would most likely rely on a central server. And given we'd be exchanging tokens for the sake of "connecting to emby", calling it part of "Emby Connect" seems fairly logical and straight forward for users to understand.

The Emby Connect servers wouldn't need to keep a track of IP's or domains so you've nothing to worry about there. The 'Short lived" in 'short lived token" really means seconds to a couple minutes. After that the token is expired anyway so unusable. So it would simply be purged from the Emby Connect servers. As with Emby Connect already, you need to be willing to trust Emby Connect to some degree to use this feature. And again! Your Emby server is not "private". It is already reporting in to the central servers regularly so it's not like it's existence and details are only known to you. The devs already have a bunch of info about your server (at least its UUID, License, Number of users, obviously IP because the connection to the central server comes from somewhere. Likely a lot more.)

Having emby admins needing to spin up nginx to host a webpage with a QR coded URL is not the point here at all if that's what you're referring to in the first paragraph. Its definitely not secure if some kind of deep linking were enabled to allow for emby login (reminder emby login is what this feature is about). We're trying to remove friction, not have people spin up entirely new services adding more friction to hosting/using emby.

As an example, I have about 15 people using my emby instance. At least every couple of months one of those 15 friends or family gets a new phone, TV, ipad, streaming device etc. Every single time I see about 3-5 failed logon attempts on my server. And those are only the ones where they typed in the URL correctly, so who knows how many attempts there really were! I also get the inevitable "How do I log into Emby again?" because they've typed their local emby instance username into the Emby Connect fields which obviously didn't work. These are the "normal" users (not the admins) who simply do not care enough to remember the app setup steps each time. They've got better things to think about and just want to hit the happy green icon and watch their shows. I also doubt I have one of the larger user bases. Sounds like your setup is only you using it so you're not really the target of this feature.

As for "worthwhile" that's totally subjective so I won't get into any debate on that. ebr and Luke both mentioned the request is being looked at so i guess ultimately they'll decide if it is worth it not us. This feature request is clearly not for you so you have the benefit of never having to use it if it gets created and you can be happy as pie logging in with your domain/port/username/password! The simple fact that this thread exists however, shows there is clearly a desire to have this friction point in UX resolved, even if only commented on by a small few (I suspect the main userbase of this feature wouldn't even know these forums exist because they would be the completely non-technical friends and family of the person who is running the Emby instance).

For some context, QR code login like we are discussing is the primary login method Apple uses for Apple TV. Username / Password is reserved as a backup, though admittedly not exactly Apples for Apples (if you don't mind the pun!) but pretty close. And Apple kind of have some experience in UX. Certainly more than you or I! And yes you are correct,  URL/port/username/password login does indeed work. But just as a mule also works perfectly fine as a mode of transport, I still want a Ferrari. No-one it trying to take your mule from you.

Again, based on what you're saying this feature is not for you. And that's absolutely fine and you'd never have to use it and can spend the rest of your days content! But so avidly objecting to the idea without really having spent time with anyone who has had this friction is a strange hill to die on my friend.

Hope this helps give you a little more understanding of the friction point this feature would solve!

[taz420nj 0]

The way I'm reading it, the best way would be to have the Android/iOS apps (only on devices with cameras) include a menu item called "Authorize Another Device For This User".  It needs to not depend on Emby Connect (In my experience EC is more of a pain in the ass than it's worth, it has been hit or miss for myself and my friends, so I just give out the server URL and assign them a username and generate a temporary password for them - which I end up having to do anyway when EC doesn't work).  That new device will connect to Emby to generate a quick expiring token and display a QR, then using another already-logged-in device select the Authorize Another Device option (which opens the camera), scan that QR, verify the token, and it links that new device to the account. I do wish the manual sign in button was much more prominent, because when giving manual login instructions you have to specify to ignore the QR code/PIN and click down to Sign In Manually.  Instead of presenting the EC QR up front on the first run, present the user with distinct buttons for Sign in with EC, Sign in manually, and Sign in with another device.

[fricelander 19]

Would be great to have the QR code working in few ways:

• displays it on the TV and if you scan it with your phone it's connecting your TV (like YouTube app) to you account
• displays it on your computer and you can scan it with your phone or iPad to connect your account on the not connected device (phone or computer)
• admin could extract QR code to send them to users directly

 

[visproduction 352]

Lots of ideas online from other projects:
 https://duckduckgo.com/?q=QR+code+auto+sign+in+development+code&ia=answer

[Nanganator 8]

On 12/05/2026 at 22:18, taz420nj said:

The way I'm reading it, the best way would be to have the Android/iOS apps (only on devices with cameras) include a menu item called "Authorize Another Device For This User".  It needs to not depend on Emby Connect (In my experience EC is more of a pain in the ass than it's worth, it has been hit or miss for myself and my friends, so I just give out the server URL and assign them a username and generate a temporary password for them - which I end up having to do anyway when EC doesn't work).  That new device will connect to Emby to generate a quick expiring token and display a QR, then using another already-logged-in device select the Authorize Another Device option (which opens the camera), scan that QR, verify the token, and it links that new device to the account. I do wish the manual sign in button was much more prominent, because when giving manual login instructions you have to specify to ignore the QR code/PIN and click down to Sign In Manually.  Instead of presenting the EC QR up front on the first run, present the user with distinct buttons for Sign in with EC, Sign in manually, and Sign in with another device.

I "think" you're suggesting the same thing as me? Only difference is you call the central service "Emby" whereas I call it "Emby Connect". I only use the term "Emby Connect" to make it clear that it is not your own Emby instance where the token exchange is happening. The exchange happens elsewhere. But you would not use the existing "Emby Connect" authentication method of email address and password. This would be a new token exchange for a Local Emby Instance account, simply facilitated by the Emby Connect central servers via QR code scanning. All completely seamless to the user.

Edited 7 hours ago by Nanganator

[Nanganator 8]

15 hours ago, visproduction said:

Lots of ideas online from other projects:
 https://duckduckgo.com/?q=QR+code+auto+sign+in+development+code&ia=answer

Yes, the idea I'm talking about is not new or novel or unique. It's just not implemented (yet! ) in Emby.

[displayname0504 21]

I had this idea in mind for this suggestion.

1. I use the Emby app to create a user account. That has the option to generate an Emby QR code which I display to the user and they scan it with their Emby app. The mobile client is then "configured" This should be easier than the second idea. 

2. For TVs and other non-mobile clients - not sure how they'd scan a QR code. This would need a central service to display a code. (The admins app?) the client would use that code to download the server info and user config. 

[Nanganator 8]

For anyone wanting to visualize the authentication flow, RFC 8628 has a good example. Device would be your TV. The "Authorization server" would be whatever infra Emby Connect is running on (or something similar). And then instead of web browser it would be the Emby app on mobile which a user is already logged into. And it would be possible to avoid the login and password bit because the user is already authenticated with the app so it would just be the confirmation code.

[Q-Droid 1022]

This could be done with QR code, short OTP or both. Also combined to allow server or client initiation. Each Emby server could handle it locally except for Emby Connect linked accounts which already have the centralized management. 

There are multiple FRs which if merged for implementation they would cover all the bases. It's up to the devs to decide when it will be important enough to give it the attention it deserves. 

 

Edited 35 minutes ago by Q-Droid