A mobile login screen is the sign-in flow of an app — branding, email and password fields, a forgot-password link, a primary submit, and social options. This snippet is a complete, working one inside a CSS phone frame, with real inline validation, a password reveal toggle, and a loading submit state, built in HTML, CSS, and vanilla JavaScript with no dependency. It's a ready starting point for any app's auth screen.

Inline validation on submit

Submitting runs lightweight validation: the email is checked against a pragmatic regex (/^[^\s@]+@[^\s@]+\.[^\s@]+$/ — non-space, an @, more non-space, a dot, a TLD), and the password for a minimum length. A failing field gets a .bad class that turns its border red and shows a specific message ("Email is required" vs "Enter a valid email address"), and focus jumps to the first problem. The error clears as soon as the user edits the field, so the form guides rather than nags.

Password show/hide

The reveal button swaps the input's type between password and text and updates its aria-label and color accordingly — the standard, accessible pattern for letting users verify what they typed without exposing it permanently. It's a single toggle with no second input.

A submit that shows progress

On a valid submit, the button enters a .loading state (disabled via pointer-events:none, lightened, label changed to "Signing in…") and, after a simulated round-trip, confirms success. In production you'd await your auth call here; the choke point is one handler, so wiring a real request is a one-line change.

The screen layout

Inside the phone frame, the screen is a scrollable column: brand row, heading, the form, an "or continue with" divider built from a flex row with ::before/::after rules, and social buttons. The status bar with a CSS battery completes the device illusion. Everything is real, focusable, keyboard-navigable DOM.

Reusing it

Drop it into a phone mockup for a marketing shot, or lift the form out of the frame to use as a responsive web login. Replace the validation and submit handler with your auth provider, keep the structure, and you have a production-ready sign-in screen.

Build with AI

Build, Understand, Optimize, and Extend It With AI

You do not have to parse the regex or the validation branching by eye. Paste this snippet's HTML, CSS, and JS into an AI coding assistant like Claude and ask it to explain exactly what the email pattern /^[^\s@]+@[^\s@]+\.[^\s@]+$/ does and does not catch, or why the submit handler checks email validity before password length rather than validating both fields at once. The same assistant is useful for optimizing it — ask whether focusing the first invalid field on every submit attempt could be jarring for users with multiple errors, or how you would debounce the input listener if you added live validation instead of validate-on-submit. It is just as good for extending the form: have it add a password-strength meter, a "remember me" checkbox wired into the submit payload, or real OAuth redirects behind the Google and Apple buttons instead of inert click handlers. Treat the code less like a finished artifact and more like a starting point for a conversation.

Prompt to recreate it

Copy this into your AI assistant of choice to build the effect from scratch, or as a jumping-off point for your own variant:

text

Build a mobile app login/sign-in screen in plain HTML, CSS, and JavaScript inside a phone-frame container — no validation library.

Requirements:
- A branding row, a heading and subheading, an email field, a password field with a show/hide toggle button, a forgot-password link, a primary submit button, a divider labeled "or continue with" built from flexbox and pseudo-element rule lines rather than an image, two social login buttons, and a footer link to create an account.
- On submit, prevent the default form submission and validate the email against a regular expression requiring non-space characters, an at sign, more non-space characters, a literal dot, and a trailing domain segment; if it fails, add an error-state class to the field's wrapper, show a message that specifically distinguishes an empty field ("Email is required") from a malformed one ("Enter a valid email address"), and move focus to the email input, without checking the password yet.
- If the email passes, validate that the password meets a minimum character length; if it fails, add the same kind of error-state class and move focus to the password field.
- Clear a field's error state and message as soon as the user types in it again, before the next submit attempt.
- The password field's show/hide button must toggle the input's type attribute between password and text, and update its own aria-label to reflect the current action ("Show password" vs "Hide password").
- On a fully valid submit, put the submit button into a disabled-looking loading state with pointer-events turned off and a changed label, then after a short simulated delay, show a success label — structured so a real async authentication call could be dropped into that same handler with minimal changes.

Want to tighten it up first? Run this prompt through the AI Prompt Studio to score it across 8 quality dimensions, catch anti-patterns, and tune the wording for Claude, ChatGPT, or Gemini before you paste it in.

Step by step

How to Use

1
Paste HTML, CSS, and JSA mobile login screen renders inside a phone frame.
2
Submit emptyThe email field turns red with a required message.
3
Enter a bad emailValidation shows a specific invalid-email error.
4
Toggle the passwordThe eye button reveals and hides what you typed.
5
Submit valid dataThe button shows a loading state then confirms success.
6
Wire your authReplace the simulated round-trip with your provider.

Real-world uses

Common Use Cases

App sign-in

Present auth inside a phone mockup.

Onboarding flows

Follow a mobile lock screen into login.

Web login pages

Lift the form out as a responsive glassmorphism login alternative.

Magic-link and OTP

Pair with magic link login or OTP verification.

Design handoff

Show the screen beside a mobile onboarding flow.

Learning form UX

A reference for inline validation and reveal toggles.

Got questions?

Frequently Asked Questions

On submit, the email is tested against the regex /^[^\s@]+@[^\s@]+\.[^\s@]+$/ — it requires non-space characters, an @, more non-space, a dot, and a domain ending. If it fails, the field gets a red border and a specific message: "Email is required" when empty, or "Enter a valid email address" when malformed. The error clears as soon as you start editing.

The eye button flips the password input's type attribute between password and text, which reveals or masks the characters, and updates the button's aria-label and color so screen readers and sighted users both know the current state. It's a single input with a toggle, not two overlapping fields.

When validation passes, the submit button gets a loading class that lightens it, disables interaction with pointer-events:none, and changes the label to "Signing in…". The snippet simulates a round-trip with a timeout then shows success; in a real app you'd await your authentication call in that same handler.

Yes. The phone frame is just a wrapper; the form and its validation are independent. Lift the form markup out and it works as a responsive web login. The frame is useful for presentations and app mockups, but nothing in the logic depends on it.

Bind the email and password to state, run the validation in your submit handler, and toggle error classes from validation results. The password reveal flips an input type bound to a showPassword flag. Replace the timeout with your auth API call and manage the loading flag in state. Tailwind styles the fields, divider, and buttons with utilities.

Loading…