Social Login Buttons — OAuth Sign In HTML CSS JS

"Continue with Google" is now the fastest, most-used way people sign in — social login removes the password step entirely and can dramatically lift signup conversion. But the buttons have to look *right*: each provider has brand guidelines for its logo, colors, and wording, and a generic gray button erodes the trust the provider's brand is supposed to lend. This snippet builds a proper social-login button set in plain HTML, CSS, and vanilla JavaScript: official-style logos, correct light/dark treatments, a loading spinner per button, and an email fallback with a terms line.

Brand-correct buttons, not generic ones

Each provider gets its own treatment: Google on a white button with its multicolor "G" mark, Apple and GitHub on dark buttons with white logos — matching each company's sign-in brand guidelines, which exist precisely so the button is instantly recognizable. The logos are inline SVGs (no image requests, crisp at any size), absolutely positioned at the left so the label stays optically centered regardless of logo width. "Continue with [Provider]" is the recommended, conversion-tested wording — clearer than "Login" or "Sign up" because it works for both new and returning users without committing to either.

A loading state per button

OAuth flows involve a redirect or popup that takes a moment to start, so each button shows a spinner the instant it's clicked — its label fades to transparent and a border-spinner appears centered, with the button becoming non-interactive to prevent double-clicks. This immediate feedback is important: without it, a user who clicks and sees nothing happen for a second will click again, potentially opening two auth flows. The spinner color adapts to the button (gray on light, white on dark).

The email fallback and divider

Social login should never be the *only* option — some users don't have or won't use a Google/Apple/GitHub account, and some organizations block them. A clear "or" divider separates the social buttons from a primary "Sign in with email" button, so the email path is always available and visually distinct. This is both a usability and an accessibility requirement: forcing social-only login excludes a real segment of users.

Terms and privacy at the point of action

A small terms-and-privacy line sits below the buttons, because the moment of account creation is exactly where consent belongs — linking the terms here (rather than burying them) is both good practice and, in many jurisdictions, a legal expectation for the signup flow. It's styled as quiet supporting text so it informs without competing with the actions.

Where the real auth goes

The click handler is where you start the provider's OAuth flow — a redirect to your /auth/google endpoint, or a call to your auth SDK's signInWithPopup / signInWithRedirect. The demo simulates the redirect delay and logs the provider; swapping in real auth is a one-line change per provider. The provider name lives in a data-provider attribute so one delegated handler covers every button, and adding a provider (Microsoft, Facebook, X) is a new button plus its logo — no new logic.