The WordPress admin area lives at your domain followed by /wp-admin. If you are not already signed in, WordPress sends you to the login form at /wp-login.php, you enter your username or email and password, and you arrive at the dashboard.
That is the whole thing when it works. Most of the questions about logging in are really about the cases where it does not, so that is what the rest of this covers.
The addresses that work
Any of these reach the login form on a standard installation:
https://example.com/wp-admin https://example.com/wp-login.php https://example.com/admin
If WordPress is installed in a subdirectory, include it, https://example.com/blog/wp-admin. Getting this wrong produces a 404 instead of a login form, which is a useful signal: a 404 means the address is wrong, not the password.
Bookmark whichever you use, with https://. Typing the domain and hunting for a login link wastes time on sites that do not have one.
Username or email
The field accepts either. If you cannot remember the username, the email address you registered with will work, which resolves this more often than people expect.
Staying logged in
The Remember Me checkbox extends the session from two days to two weeks. It is convenient on your own machine and a bad idea on a shared one, because it leaves a valid session cookie behind after you close the browser.
Use Log Out from the account menu rather than just closing the tab when you are on a machine that is not yours. Closing the tab leaves the session alive.
Resetting a forgotten password
Click Lost your password, enter the username or email, and WordPress emails a reset link. The link expires, so use it promptly.
If the email never arrives, check spam first, then consider that the site may not be sending mail at all. WordPress uses the server's mail function by default and it fails quietly on plenty of setups. A site that cannot send a password reset also cannot send order confirmations, so this is worth discovering now.
Resetting a password without email
When mail is broken and you are locked out, change the password directly in the database.
Open phpMyAdmin from cPanel, select the site's database, and open the wp_users table. The prefix may differ if it was changed at install time. Find your row and edit it.
In the user_pass field, type the new password in plain text, then select MD5 in the function dropdown beside that field. That dropdown is the entire trick. Without it the password is stored as literal text and will never match; with it WordPress can read the value and will upgrade it to its own stronger format at your next login.
Save, then log in with the new password. Managing MySQL databases with phpMyAdmin explains finding your way around that interface.
Locked out by too many attempts
Security plugins block an address after repeated failures, which is doing its job: automated login attempts run against every WordPress site continuously.
Waiting out the lockout period is the simplest fix. If you cannot wait, disable the plugin by renaming its folder inside wp-content/plugins over SFTP, adding -off to the end. Log in, clear the block from the plugin's settings, then rename the folder back.
Do not leave it disabled. The lockout that inconvenienced you is the same one stopping the attempts you never see.
The login page loads but the password never works
If you are certain the password is right and the form simply returns to itself, the usual cause is cookies. The session cookie is issued for one address and checked against another, typically www versus the bare domain, or http versus https.
Make sure you are loading exactly the address configured in WordPress. If the mismatch persists, set both values explicitly in wp-config.php:
define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' );
Clearing cookies for the domain resolves the leftover-session version of this. A redirect loop between the two addresses is the same problem wearing a different symptom.
Errors instead of a login form
A blank page or a 500 error at the login URL is not a login problem. It is a broken site that happens to be broken at that URL. Turn on the debug log and read what the server says; fixing common WordPress errors starts there.
If the front end works and only the admin area fails, a plugin is the likely cause. Rename the whole wp-content/plugins folder to plugins-off to deactivate everything at once, log in, then rename it back and reactivate one at a time.
Protecting the login
The login form is the most attacked part of any WordPress site, and the attacks are automated rather than personal. Three things make them ineffective.
Do not use admin as a username: it is the first guess every time. Use a long unique password stored in a password manager, so a breach somewhere else cannot be replayed here. And add two-factor authentication to any account that can install plugins, which makes a stolen password useless on its own.
Moving the login to a different URL is sometimes suggested as a fourth. It stops naive scanners and nothing else; it is not harmful, but do not count it as a defence. Securing WordPress against vulnerabilities puts these in order of how much risk they actually remove.
Keep a second way in
Access to the administration screen depends on several things working at once, and losing any of them locks you out. A second administrator account, held by somebody else, is the cheapest protection available. Beyond that, access to the files or the database is what allows recovery when the login itself is the problem, and confirming you have one of those before you need it is worth a minute. The situation to avoid is a single account, a single person, and no route to the files, which turns a forgotten password into a rebuild.