Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Minimal Sign In Login Block for React

A bare sign-in page for a plain-text notes app: a heading, one sentence, an email and a password written on a hairline and one Sign in button, set at the start of the page with no card, providers or footer.

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

Give a focused app a sign-in that is only the form, with this minimal login block for React with Base UI. It's the sign-in of Scribbin, a plain-text notes app: the page's two side rails run its full height and one band crosses the screen between two rules with a plus mark where each meets a rail, and in the band, at the start of the line rather than its middle, sits a column with nothing else on the page. A heading and one sentence lead into a Field with an email Input and another with a Password Input and its show and hide toggle, each written on a hairline instead of in a box, with "Forgot password?" at the end of the password's label row, and the Shine Button signs in, the only colored control. Pressing it with something missing marks both fields, writes each problem under its field and moves focus to the first; a good press shows a spinner for a moment, then puts the result in the form's own space and moves focus to it, so the page never changes height. There are no providers, no legal line and no footer. It's built from Field, Input, Password Input, Button, Shine Button and Guides, with a CSS entrance only. For notes apps, admin panels and any product that wants a distraction-free gate.

FAQ

What happens when I sign in, and what stays in the page?

Nothing leaves the page. Sign in waits under a spinner for less than a second, then shows "You're signed in" with the address you typed, and a polite status message says nothing was sent; Sign out brings the form back with your email still filled in. To wire it for real, post the email and password to your auth endpoint where the code says so (a server action or your auth library's sign-in call), keep the busy state until it answers, then redirect, or show its error under the field it concerns.

Why is the Sign in button never disabled?

A disabled button can't explain itself, and keyboard users can't reach it. Here it stays enabled: pressing it with an empty or malformed email, or no password, marks those fields invalid, writes one sentence under each and moves focus to the first, which reads its problem out. Typing clears that field's problem. The browser's own validation bubbles are turned off with noValidate, so the messages look the same everywhere, and each field keeps a line for its problem even when there is none, so a problem never pushes the page.

How are the fields drawn without a box?

The Input and the password's group take classes that remove the border on three sides, the fill and the corners, and keep a line under the text. The line is a foreground tone, because the style's own border is too pale to be a field's only edge; keyboard focus adds a second pixel in the full foreground color, and a wrong field's line turns the status color. The labels stay visible above the fields, so a field never loses its name once it has text.

Do password managers fill it in?

Yes. The email field is type="email" with autocomplete="username", and the password field autocomplete="current-password", which is what browsers and password managers look for on a sign-in form. Both fields have real labels and names. For a sign-up page, use new-password on the password so managers offer to generate one.

Why does the form sit at the start of the band, and can I center it?

The slug's idea is that nothing but the form is on the page, so the column is max-w-xs and starts at the band's start edge, a little inside the rail, instead of floating in the middle; in a right-to-left language it moves to the other side with no change. To center it, add mx-auto to the column and drop the lg:ms-12 offset. On a phone the column fills the width either way.

Is it usable with a keyboard and a screen reader?

Tab runs through the email, the password, its show and hide toggle (a named button, pressed while the password shows), Forgot password and Sign in; Enter in either field signs in. The heading names the form, each problem is tied to its field, and after signing in focus moves to the result's heading while a polite status message says what happened, so screen reader users hear the outcome.

  • 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

    A member sign-in page whose labels sit inside the fields and rise on focus, with text or when the browser fills them in, all in CSS, in one bordered group of two cells split by a hairline.

  • Pro

    A sign-in page that is the whole screen: a top row with the product's mark and a create-account link, the form centered between rows, a footer row of links and a faint dot grid, with a Caps Lock note under the password.

  • Pro

    A sign-in page where the band's top rule is the progress line: pressing Sign in locks the fields and a line fills across the rule in 800 ms, then a line in the foot's place says what happened and offers Try again.

  • Pro

    A sign-in strip as a panel: a short header over one framed row with the product's mark, an email, a password and a Sign in button, which stack below 1024 px and swap for a row of the same height once signed in.

  • Pro

    Alert Banner Login

    Centered form

    A full-height sign-in page for a database host with a maintenance notice pinned above the form: a quiet alert with the window in UTC, a Details popover and a Dismiss that never moves the form.