I was wondering if passwords' inputs are "converted" locally on the client/web browser side or on the server side.
Usually (with regular forms-based logins) everything is done on the server side.
but in that case it brings a concern to me: that means you are sending your password to a third party. Indeed the password will travel in a secure channel to the server, but in the end the server could do whatever it wants with it
Yes it could. Hence the admonitions against password reuse.
Computing the hash yourself and sending it to the server would make the authentication process so much more secure.
On its own – no, it won't. It'll trade one risk for another.
With server-side hashing, if the server's database leaks (which happens a lot more often than TLS MITM), those hashes are mostly useless unless cracked one by one. With client-side hashing, the attacker could simply start sending those hashes like they were passwords! Instead of a one-time DB leak, now the attacker can log in to everyone's accounts, and they can keep those hashes to themselves and use them to log in months or years later.
(If you made both sides (first client, then server) hash the passwords, this still wouldn't stop a malicious server from storing the client-sent hashes and re-sending them somewhere else, again like passwords.)
To actually avoid both issues, you'd need more than just hashing; you'd need a slightly more complex protocol (e.g. some kind of challenge/response that isn't completely misdesigned like "HTTP Digest" was). You'd also want to ensure that the hash sent by the client cannot be reused at a later time (or even on a different site), as "replay attacks" are an issue with many protocols.
For example, the SCRAM protocol is now somewhat common among non-web systems such as PostgreSQL or MongoDB. However, to a web developer, all of those are significantly more complex than just making an HTML