It's unclear whether, by "private key", you mean in the sense of an asymmetric public/private key pair, or simple a generic secret. The term "private key" usually means the first ("private" as opposed to "public"), but the rest of what you say makes it sound more like the second (which might be termed an "access key" or simply "secret key"). Since this isn't clear, I'll answer for both cases.
If you mean an asymmetric private key: Don't. You shouldn't ever need to transmit one of those over the Internet. Private keys should be generated in situ wherever they are to be used, and if they need to be portable then they should be placed in encrypted form on physically secure (and potentially also encrypted or at least password-secured) storage (and that storage wiped, securely, once the key no longer needs to be on it). Ideally, a private key is only ever stored in one place; if that's not practical, it should at least never be stored - or, ideally, even transmitted through - somewhere that you don't control. If for some reason a private key is actually required here and you can't generate it in situ, then encrypting it with a passphrase (this is standard when you generate or export a private key) and passing the encrypted key through TLS is acceptable. Of course, that assumes there's some way to get the passphrase into the system too, ideally through a different vector so that there isn't a single point of failure for everything. If not... sending a private key through TLS isn't inherently insecure - TLS is a very good protocol, we secure pretty much all forms and sensitivities of secrets with it all the time - so sending the key just through TLS is probably OK. However, if it comes to that, somebody has screwed up the design of their system quite badly.
If you mean an access key or other generic secret: As mentioned above, TLS provides very good security (assuming it's configured correctly and the keys are stored securely). If there's a convenient way to avoid exposing the key to the TLS tunnel directly - e.g. an easy way to "wrap" and "unwrap" it (encrypting and decrypting it with another key or key pair that is available, and of course isn't itself being sent over the same tunnel) - do that, and then send the wrapped key over TLS and unwrap it separately at the far end. Alternatively, if the server actually only needs something like the key's hash digest, you could hash it on the client side and upload that. Unlike private keys, though, it's quite common to send secrets (passwords, access keys, session tokens, password reset links, etc.) through the Internet, via TLS. You can sometimes do better when actually using the secret - Secure Remote Password protocol for passwords, or signing a message with an HMAC (or multiple HMACs, as AWS does) using an access key rather than exposing the key to the network directly - but the first step of setting up the key generally requires transmitting it in some form (especially if it is generated on a third-party system), and TLS is ideal for that.
For both cases: Note that web app security is heavily dependent upon both the security of TLS, and the trustworthiness of the web server (and, by extension, of all code that the web server tells the client to load, such as third-party JS). If an attacker can breach TLS, then they can probably read the request you sent to GET the upload page (meaning they'll have whatever authentication token you used in this process), or modify the response from the webserver (meaning they can cause it to contain arbitrary malicious JS that captures everything you do, including any passphrase or similar that you enter). Same if the attacker controls the server (or even just some content that it serves, or that the served page loads), of course. Consider your threat model closely when deciding what level of security is needed.
