Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Remember Device Login Block for React

A full-height sign-in page for an email client where trusting the browser is a choice with a consequence: a switch opens a 7, 30 or 90 day choice and a live line works out the date from a typed today.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Make trusting a browser a choice people can read, with this remember device login block for React with Base UI. It's the sign-in of Mailkeel, an email client: the page's side rails run the full height of the screen and one band crosses it between two rules, with a start-aligned header over a hairline and two cells split by a divider. At the start sit a Field with an Input for the email and another with a Password Input. At the end, a "Trust this browser" Switch with its warning about shared computers opens a three-way Segment Group of 7, 30 or 90 days, a line that works the date out from a typed "today" ("You won't be asked for a code on this browser until Nov 13, 2026"), and the Shine Button that signs in, the only colored control. The choice's room is held, quiet while the switch is off, so nothing moves. The divider meets the hairline and the band's rule at plus marks, ruled by Guides. It's built from Switch, Segment Group, Field, Input, Password Input, Button, Shine Button and Guides, with a CSS entrance only. For any product that asks for a code on new browsers.

FAQ

What stays in the page, and what would a real product do?

Nothing is stored: no cookie is set and the choice is gone on reload. Sign-in waits under a spinner for less than a second, then shows "You're signed in", whether this browser is trusted and until when, and a polite status message says nothing was stored. A real product sets a signed, HttpOnly cookie only when trust is on, with an expiry the server checks, and skips the code step only while that cookie is valid. Post the form to your auth endpoint where the code says so.

How is the date worked out?

From a typed "today" (midnight UTC on 2026-10-14) plus the number of days, in UTC, and written with Intl.DateTimeFormat, so the server and every visitor's time zone print the same day. It never reads the clock when the page renders. In a product the server decides the expiry and sends the date back, and the page only prints it.

What about shared computers?

Trust starts off, so someone has to choose it, and the warning sits beside the switch where the choice is made. Beyond the page: make the cookie revocable from a list of trusted browsers in the account's settings, drop every trusted browser when the password changes or a security event happens, and ask for the password again before sensitive actions even on a trusted browser.

Why 7, 30 and 90 days?

They are common defaults, a week for caution, a month as the usual, and a quarter for a personal laptop; pick the set that matches how risky an unlocked mailbox is for your users. The choices are the DURATIONS array: each has its number of days, its label and a value, and the date line follows the one that is chosen.

Why is the 7, 30, 90 choice visible while trust is off?

Hiding it would leave a hole in the middle of a centered page, and revealing it would move the Sign in button under the pointer. It stays in place, quiet and out of reach of the keyboard, with no selected segment until the switch is on; then the choice wakes up with 30 days selected, and a polite message reads the new date out.

Why is the Sign in button never disabled?

A disabled button can't explain itself, and keyboard users can't reach it. Pressing Sign in with an empty or malformed email, or no password, marks those fields invalid, writes one sentence under each and moves focus to the first. Typing clears that field's problem, and each field keeps a line for its problem even when there is none.

  • Pro

    A panel of trusted devices for a smart-home app: each has a trust-expiry meter, Forget asks in an alert dialog, Undo brings the last one back and a Shine Button trusts this browser for 30 days.

  • Pro

    Device Approval Login

    Codes and approvals

    A sign-in screen with a drawn phone: it asks whether the request is you, shows three number buttons, approves the matching one, denies a wrong one and points Deny to a password change.

  • Pro

    A split sign-in step for an investing app: a six-digit code field beside a demo authenticator whose code and draining ring change every 30 seconds, where the current code and the one before it both sign in.

  • Pro

    Session Limit Login

    Sessions and devices

    A sign-in gate for a video streaming service: a meter of screens in use, three sessions as radio rows, and one button that ends the chosen session so this browser can continue.

  • Pro

    A full-height sign-in page for a team chat app: the product's mark, Google and GitHub rows with lettermark tiles, an or rule, email and password checked on submit, and one Sign in button with a simulated wait and its result.

  • Pro

    Session Expired Login

    Sessions and devices

    A re-authentication page for a document editor that keeps the email read-only, asks only for the password, shows where you were, and confirms before switching account.