Free · Fast · Privacy-first

CSS Slide In Animation

Slide-in animations move elements into view from outside their natural position, communicating directionality and spatial context to the user in a way that a simple fade-in cannot.

⚡

Slide from left, right, top, or bottom

🔒

Control entry distance from subtle to full-panel

✨

Combine with opacity for a polished entrance

⚡

Generates overflow-safe CSS for the parent container

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Animation Builder to your website

Drop the Animation Builder into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/css-tool/animation-builder?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Animation Builder by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/css-tool/animation-builder?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Animation Builder by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

How CSS Slide-In Animations Work and How to Choose Direction and Distance

A slide-in animation works by starting the element at an offset position using CSS transform: translateX() or translateY(), then animating that offset back to 0 over the animation duration. The translateX value shifts the element horizontally: a positive value moves the element to the right of its natural position so it slides in from the right, while a negative value moves it left so it slides in from the left. The translateY value shifts it vertically: a positive value places the element below its final position so it slides up into view, and a negative value places it above so it slides down. Because translate values are relative to the element itself rather than the viewport, the starting position scales with the element size unless you use a fixed pixel value. A starting value of translateX(100%) slides the element in from entirely off its own right edge regardless of element width, while translateX(30px) slides it in from just 30 pixels offset and produces the same visual distance regardless of element size.

Choosing direction and distance communicates spatial meaning to the user that goes beyond the surface aesthetic of the motion. Sliding from the left is the standard direction for navigation drawers in most design systems, matching the convention that primary navigation lives to the left of the main content in left-to-right writing systems. Sliding from the bottom is the standard for mobile modal sheets, action menus, and contextual confirmations, matching the iOS and Android native pattern of secondary content rising from the bottom of the screen. Sliding from the top suits dropdown menus, notification panels, and announcement banners. The distance determines how dramatic the entrance feels: 20 to 30 pixels creates a subtle entrance suitable for cards and tooltips that should feel like they nudged into view, while 100 percent creates a full-panel entrance suitable for navigation drawers and full-screen modals that should feel like they came from off-screen entirely.

Containing the animation is a practical concern that code examples often omit and that causes the most common slide-in bug shipped to production. During the translate phase, the animating element exists at a position outside its natural layout position. If the parent container does not have overflow: hidden, the browser renders a horizontal or vertical scrollbar during the slide-in to accommodate the temporarily out-of-bounds element, which is almost always undesirable and looks like an unintended layout glitch. Adding overflow: hidden to the parent element containing the slide-in target prevents the scrollbar entirely. For navigation drawers that slide over the page rather than within a container, apply overflow: hidden to the document body during the animation and remove it after the transition completes using a JavaScript class toggle, so normal page scrolling resumes once the drawer is settled.

Combining a slide-in with a fade-in is one of the highest-leverage upgrades to the basic slide pattern, and it eliminates the visual oddity of the element being visible at its off-screen starting position before the animation begins. Without a fade, the user can briefly see the element popping into existence at its offset position the moment the animation class is added, which is most obvious on slower connections where the CSS may apply a frame or two before the keyframes start playing. Adding opacity: 0 at the 0 percent keyframe and opacity: 1 at 100 percent solves this completely: the element fades up from invisible to fully visible while simultaneously sliding into position, so the off-screen starting point is never seen by the user. Both transform and opacity animate on the compositor thread, so the combined effect has no measurable performance cost compared to the slide alone, and the polished result is the convention in most modern UI frameworks for a reason.

MDN: CSS Animations W3C CSS Animations Specification

How to use this tool

💡

Choose an entry direction and distance. Add a fade-in by enabling the opacity option. Set duration and easing, then preview the slide. Copy the code and add overflow: hidden to the parent to prevent a scrollbar during the translate phase.

How It Works

Step-by-step guide to css slide in animation:

1
Choose slide direction
Select the entry direction from the four options: from left, right, top, or bottom. Match the direction to the established UI pattern for the element type. Use from-left for navigation drawers, from-bottom for mobile sheets and toasts on phones, from-top for dropdowns and notification banners, and from-right for contextual detail panels that supplement the main content. Inconsistent slide directions across components break the user's spatial model of the interface.
2
Set entry distance
Enter the starting translate distance using either a pixel value or a percentage. Use 20 to 30 pixels for subtle card entrances that feel like the element nudged into view from just outside its current position. Use 100 percent for full-panel slides where the element should start completely off its own edge regardless of width. Choose a fixed pixel value rather than a percentage when you need predictable behavior independent of element size, such as inline alerts that may be any width.
3
Enable opacity fade (optional)
Turn on the opacity option to combine the slide with a fade-in, which is the recommended pattern for almost every slide-in use case. Starting opacity at 0 and ending at 1 prevents the element from being briefly visible at its off-screen starting position, which can flash for a frame on slower connections before the animation begins. The combined slide-and-fade adds no performance cost because both transform and opacity run on the compositor thread, and it produces a more polished result.
4
Add overflow: hidden to the parent
After pasting the generated code into your stylesheet, add overflow: hidden to the parent element containing the slide-in target to prevent a scrollbar appearing during the translate phase. For full-viewport drawers, apply overflow: hidden to the body element during the animation and remove it after the transition completes via a JavaScript class toggle so normal scrolling resumes once the drawer is settled. This single addition prevents the most common slide-in bug shipped to production.

Real-world examples

Common situations where this approach makes a real difference:

Mobile navigation drawer

A mobile app developer creates a left-side navigation drawer using a translateX(-100%) to translateX(0) animation with 300ms ease-out easing applied via a CSS transition rather than a keyframe animation so the drawer can reverse cleanly when closed. The drawer is positioned fixed and slides over the page content when a hamburger button toggles the open class. Overflow: hidden on the body prevents a horizontal scrollbar during the slide, and is removed once the drawer is closed so normal page scrolling resumes. A semi-transparent backdrop fades in simultaneously to dim the content behind the drawer and to act as a click target for closing.

Bottom action sheet on mobile

A mobile web developer builds an action sheet component using translateY(100%) to translateY(0) with ease-out easing at 250 milliseconds, matching the iOS and Android native pattern of contextual sheets rising from the bottom of the screen. The sheet contains a list of actions (Share, Edit, Delete) presented over a dimmed backdrop that fades in simultaneously with the sheet slide. The distance is 100 percent rather than a fixed pixel value to ensure the sheet starts below the viewport regardless of how much content it contains, which avoids the bug where a tall sheet remains partially visible at its starting position before the animation begins.

Card entrance in a content feed

A social feed component applies a translateX(-20px) to translateX(0) with opacity 0 to 1 entrance to each new card appended to the feed as the user scrolls or as new posts arrive. The 20-pixel offset is subtle enough to create a sense of motion without making the card appear to come from off-screen entirely, and the combined fade prevents the card from being briefly visible at its offset starting position. Duration is set to 200 milliseconds for a responsive feel that does not delay the user's scrolling, and the same animation class is applied to every new card so the entrance behavior stays consistent regardless of the card content type.

Inline notification slide-in

A form validation system slides error messages in from the right side using translateX(10px) to translateX(0) combined with opacity 0 to 1 at 180 milliseconds ease-out, applied when the validation handler adds an error class to the message container. The rightward origin gives the message a subtle sense of arriving from outside the current focus area without the abrupt feel of a simple opacity flash. The short duration keeps the UI feeling snappy and ensures the user does not feel the form is unresponsive during validation. The same pattern is reused for success and warning messages with only the color and icon changing.

When to use this guide

Use this when building navigation drawers, side panels, modals that enter from below, or any element that should enter from a specific direction rather than appearing in place.

Pro tips

Get better results with these expert suggestions:

Use translateX percentages for responsive elements

Using translateX(100%) rather than a fixed pixel value makes the slide-in distance scale automatically with the element size, which is the correct behavior for navigation drawers and full-panel slides where the element must start completely off its own edge regardless of viewport size or content height. Use fixed pixel values like translateX(30px) only when you want a consistent subtle offset regardless of element width, such as for inline card entrances where the absolute distance matters more than the proportional offset, or for short alerts where a 30px nudge always looks right.

Add overflow: hidden to the right parent, not the body

Adding overflow: hidden to the document body prevents all page scrolling, which can create a jarring experience if the user was mid-scroll when the animation started or if the slide-in element is shorter than the viewport. Instead, identify the nearest ancestor element that fully contains the slide-in target's animation path and apply overflow: hidden there. For an element sliding within a sidebar, that ancestor is the sidebar container, not the body. Reserve body overflow: hidden for full-page drawer overlays where the drawer covers the entire viewport.

Match slide direction to the spatial model of your UI

Navigation that logically lives to the left of the content should slide in from the left. Contextual detail panels that supplement the main content should slide from the right. Content that stacks below the current view (action sheets, toasts, contextual menus) should rise from the bottom. Notification banners and announcement bars should drop from the top. Inconsistent slide directions break the user's mental model of where UI elements live spatially and force them to relearn the spatial geometry every time they encounter a new component.

Test slide-in animations at both 300ms and 600ms before deciding

The difference between 300ms and 600ms for a full-panel slide is perceptible and meaningful, and the right choice depends entirely on the role of the element. 300 milliseconds feels snappy and functional, appropriate for utility panels users open many times in a session like settings drawers and filter panels. 600 milliseconds feels premium and deliberate, appropriate for branded hero moments like onboarding overlays and empty-state CTAs. Test both durations side by side in the live preview before committing, and consider that the right answer often falls between the two values rather than at either extreme.

FAQ

Frequently asked questions

translateX(100%) moves the element by 100 percent of its own width, so a 300px wide drawer translates by 300px regardless of viewport size. translateX(100vw) moves it by 100 percent of the viewport width, so the same drawer translates by however wide the current viewport is. If the element is narrower than the viewport, translateX(100%) will not slide it fully off-screen, leaving a visible edge of the element during what should be the off-screen starting state. For a navigation drawer that should enter from completely off-screen regardless of element width, translateX(100vw) (or a negative value translateX(-100vw) for a left-side drawer) guarantees the element starts completely outside the viewport. Use percentage units for self-contained slides where the element's own dimensions define the motion distance, and viewport units when the element must clear the viewport entirely.

During the translate phase, the element exists at a position that extends outside the container boundary, sometimes outside the viewport itself. If the container does not have overflow: hidden, the browser renders a scrollbar to accommodate the out-of-bounds element, even though the overflow is temporary. Add overflow: hidden to the direct parent element of the animated element to prevent the scrollbar. For full-viewport slides where the element travels across the page edge, add overflow-x: hidden to the body element specifically. Be aware that overflow: hidden on the body also prevents intentional scrolling of the page content, so apply it only during the animation duration and remove it via JavaScript afterward to restore normal scroll behavior.

Use a CSS transition when the slide-in is triggered by a class toggle, such as a navigation drawer that opens when a menu button is clicked, because transitions reverse automatically when the class is removed, making the exit slide-out free without any additional code. Use a CSS animation when the slide-in happens on page load or element insertion without a class toggle mechanism, because animations play immediately when applied and do not require a property change to trigger. For toggleable panels and drawers, transitions are simpler and require fewer event listeners. For entrance-only effects like staggered list reveals or hero section animations, animations are more appropriate because they play once on render and do not need to support a reverse path.

A CSS animation for exit must be triggered separately from the entrance animation because the entrance animation completes and then the element stays in place. The standard approach is to add an exit class to the element before removing it from the DOM, where the exit class applies a reverse slide animation translating from 0 back to the starting offset with the same duration as the entrance. Use an animationend event listener on the element to remove it from the DOM only after the exit animation completes, preventing it from being removed before the slide-out is fully visible. For framework-based components, libraries like Framer Motion or React Transition Group provide built-in exit-animation orchestration that handles this lifecycle automatically.

Yes, and combining them is the recommended pattern for most slide-in animations because it produces a more polished result than either effect alone. Add both translateX (or translateY) and opacity: 0 at the 0 percent keyframe stop, and both translateX(0) and opacity: 1 at the 100 percent stop. Both properties animate simultaneously over the same duration with the same easing, and since both transform and opacity run on the compositor thread, there is no performance penalty for combining them. The combined effect is more polished than either animation alone because the opacity prevents the element from being briefly visible at its starting offset position, which can flash for a frame on slower devices.

Ease-out is the standard choice for slide-in entrances because it starts quickly so the element appears to move with purpose, then decelerates as it arrives at its final position to mimic natural settling behavior under deceleration. A custom cubic-bezier like cubic-bezier(0.25, 1, 0.5, 1) adds a slight overshoot followed by a settle, creating a spring-like feel appropriate for drawers, panels, and other UI elements where a small physical bounce reinforces the interaction. Avoid ease-in for slide-ins because the slow start makes the element feel like it is reluctantly appearing, and avoid linear easing because the constant velocity reads as mechanical motion rather than the natural arrival of a physical object.

Add a @media (prefers-reduced-motion: reduce) rule that sets animation: none for the slide-in class, causing the element to appear instantly at its final position for users who have requested reduced motion in their OS settings. This is required under WCAG 2.1 guideline 2.3.3 for non-essential animations. Also consider focus management: for navigation drawers and modal panels that slide in to reveal interactive content, move keyboard focus to the first interactive element inside the panel after the slide-in completes using element.focus() inside an animationend handler. This ensures keyboard users and screen reader users can access the new content without having to navigate past the page content behind it manually.

No. CSS transform (including translateX and translateY) does not affect document layout in any way. The element's layout position and the space it occupies in the document flow remain unchanged throughout the animation, with the transform only shifting the visual rendering relative to the layout box. Surrounding elements do not shift during the slide-in, and the page does not reflow at any point in the animation. This is a key advantage of using translateX and translateY over animating the left, right, top, or margin properties, all of which do affect layout and cause surrounding elements to reflow on every animation frame, producing significantly worse performance and visual stability.

Yes. CSS transform applies independently of the element's positioning scheme, so a slide-in animation works identically on position: static, relative, absolute, fixed, or sticky elements. For drawers and modals that use position: fixed to overlay the page, the slide-in animation works exactly the same as on a static element. The only consideration is that absolutely positioned elements may interact with transform-origin in unexpected ways if you combine the translate with a scale; for pure translate slide-ins, no extra adjustment is needed. Combining a fixed-position drawer with a translateX slide and a backdrop fade is the canonical mobile navigation pattern across iOS, Android, and web design systems.

Virtualized lists (used by libraries like react-window and react-virtual to render only the visible items in a long list) reuse DOM nodes as the user scrolls, which interacts oddly with entrance animations because the same node may receive multiple slide-in classes over time. The standard solution is to disable slide-in animations on virtualized list items entirely, since the user perceives the items as static content rather than newly appearing elements during scroll. If you do want an entrance effect, trigger it only on the initial render of each item using a one-time state flag, not on every recycle, to avoid distracting flickering as the user scrolls.