Magic UI — animated React components you copy into your own codebase

Copy-paste animated React components built on Tailwind and Motion. See what the MIT library includes, what the one-time Pro licence adds.

  • React Components
  • Tailwind CSS
  • UI Animation
  • Landing Pages
  • Open Source
Publisher
Magic UI
Type
Animated React Component Library
Pricing
Freemium
Reviewed
19 September 2026
Official site

Quick verdict

Use when

  • You are building a marketing page, landing page or portfolio in React and need motion that looks considered rather than assembled
  • Your project already uses a copy-paste component approach and you want animated pieces that follow the same conventions
  • You want to own the code rather than depend on a package that will change under you
  • You need hero sections, marquees, background effects, device mockups and text animation in one place instead of three
  • Your budget is zero and you would rather not put a subscription in front of a page you are still designing

Skip when

  • You need accessible application primitives — form controls, data tables, dialogs, navigation — which is a different library and a different job
  • You are not using Tailwind CSS, or you are not on React, because almost nothing here transplants cleanly
  • You want a design system with tokens, theming and governance rather than a catalogue of effects
  • Nobody on the team will maintain copied code; every component you paste in is yours to keep working
  • You are building a product UI where restraint matters more than impact

Try instead

If you want a wider catalogue of animated React components, or a component set aimed at application screens rather than landing pages, those live here too.

Magic UI vs shadcn/ui vs Aceternity UI vs React Bits

These four are often mentioned together and they are not substitutes. shadcn/ui is the foundation most of the others assume: accessible application primitives — buttons, dialogs, tables, forms — installed into your repo and owned by you, deliberately plain so that you style them. Magic UI, Aceternity UI and React Bits all sit one layer up, in marketing and presentation: animated hero sections, marquees, beams, background effects, text reveals. Between those three the difference is catalogue shape and commercial model rather than quality. Magic UI's free library is MIT-licensed and genuinely free, with animation work that reads as tasteful rather than novelty, and a paid tier that is a one-time licence for whole page sections and templates rather than a subscription. Aceternity runs a larger premium catalogue behind an all-access pass with both annual and lifetime options, and its style is more maximal. React Bits is the closest sibling in spirit: a large open-source animated catalogue with a freemium tier of its own. The practical answer for most React projects is to use a primitives library for the application and one of these three for the marketing surface — and to pick whichever one's previews you would actually ship, because that judgement does not transfer between them.

Tap a dimension to focus

Pricing

Magic UI leads
  • Magic UIThis page
    • The component library is free and MIT-licensed, with no cap on which components you can use
    • The paid tier is a separate product — page sections and templates — bought once at an individual licence, not a subscription
    • No per-seat cost and no renewal to keep using what you have already pasted into your repo
    • Lifetime access and updates are included with the one-time purchase
    • Free and open source, with no paid tier for the library itself
    • There is an adjacent paid offering around blocks and templates, separate from the primitives
    • You pay in maintenance rather than licence: copied components are yours to keep working
    • No subscription is required for anything in the core component set
    • A substantial free subset of components that anyone can copy
    • The premium catalogue sits behind an all-access pass offered as either an annual subscription or a one-time lifetime purchase
    • The lifetime option is the closer comparison to a perpetual licence
    • The paid tier covers component blocks and full templates rather than the free components
    • Free open-source animated components with a paid tier alongside
    • The paid element unlocks part of the catalogue rather than the whole library
    • No subscription is needed to use what is free
    • Commercial use of the free components is permitted under the project licence
  1. Magic UI — official site
  2. Magic UI — documentation
  3. Magic UI Pro — sections and templates
  4. Magic UI — source on GitHub
  5. Magic UI — community Discord
  6. shadcn/ui — official site
  7. Aceternity UI — official site
  8. Magic UI — component documentation

Preview of Magic UI - not the live app. Confirm details on the official site.

Does this overview help you decide?

(—)

Learn more

Details below the decision summary—features, workflow, and scope notes.

What is Magic UI?

Copy-paste animated React components built on Tailwind and Motion. See what the MIT library includes, what the one-time Pro licence adds.

What it costs

A free, MIT-licensed component library, plus a separate one-time licence for page sections and templates.
Free tier
Yes
Pricing summary
The cost structure here is genuinely simple, and it is worth stating precisely because the category has trained everyone to expect the opposite. The component library is free and MIT-licensed: you can use it commercially, modify it, and ship it without paying anything or crediting anyone. The paid product is a different and narrower thing — page sections and full templates built on the same foundations — sold as a single one-time purchase at an individual licence, with lifetime access and updates included, commercial use permitted, and the one meaningful restriction being that you cannot resell the code itself. There is no subscription, no per-seat pricing and no gate that switches off components you are already using, which puts it in a different commercial category from the annual-access model that the closest alternative in this space uses. The costs that do not appear on the page are the two that matter over time. The first is maintenance: components are pasted into your repository, so you own them, and an upstream improvement will not arrive in your project unless you go and get it — a deliberate trade that buys you control and costs you a migration whenever you want the newer version. The second is the animation dependency itself, which has to be installed and is then part of your bundle; the visual payoff is real and it is not weightless. The sensible way to approach it is to use the free library first and only buy the sections if you find yourself rebuilding the same page furniture repeatedly. Confirm the current licence terms on the official pages before purchasing: the free/paid split has been stable, and a licence is exactly the kind of thing where the wording matters more than the summary.

Reviewed on 19 September 2026 · Magic UI Pro — sections and templates

What Magic UI includes

The catalogue as the project organises it, read against what each group is actually for.
  • A large free set of animated components

    Over a hundred components and effects, all free and MIT-licensed, spanning the pieces a landing page needs: marquees, bento grids, animated lists, orbiting circles, icon clouds, lens effects and pointer followers. The important property is that they look finished on arrival rather than needing a designer to rescue them, which is the difference between a component catalogue and a starter kit.

  • Text animation built in

    A dedicated group covers animated gradient text, typing and number tickers, word rotation, text reveal and morphing effects, which are normally the parts teams hand-roll badly. Having them in the same catalogue as the layout components means a page can be assembled from one place with a consistent motion language rather than from three sources with three feels.

  • Background and special effects as first-class components

    Animated grids, dot and hexagon patterns, retro and flickering grids, light rays, particles, meteors, beams and shine borders are catalogued as components in their own right. This is where a lot of the perceived polish on modern landing pages comes from, and treating them as reusable pieces rather than bespoke CSS is the practical value.

  • Device mockups for product shots

    Safari, iPhone and Android frames let you place a real screenshot inside plausible hardware instead of paying for a mockup file or composing one by hand. It is an unglamorous feature that saves a specific and recurring afternoon every time a product page needs a hero image.

  • Copy-and-paste distribution rather than a dependency

    Components are added to your project as source rather than imported from a package, using the same conventions as the primitives library this is designed to sit beside. You get full control and no version lock; in exchange there is no automatic upgrade path, and staying current is a deliberate act rather than a merged pull request.

  • Tailwind, TypeScript and a motion library underneath

    Everything assumes a modern React stack with Tailwind for styling and a motion library for animation, and leans on TypeScript throughout. That makes adoption trivial inside a project already shaped that way and a poor fit anywhere else — this is not a library that transplants into a Vue codebase or a project without Tailwind.

  • Page sections and templates in the paid tier

    The one-time Pro licence adds ready-made blocks for the parts of a landing page everyone rebuilds — headers, heroes, social proof, features, pricing, footers — plus complete templates for common product shapes. It is a different kind of asset from the components: less a primitive and more a finished page you can adapt, which is exactly what a solo builder or a small team is short of.

  • An open-source project with a real community around it

    The library is developed in public with tens of thousands of stars, a documented contribution path and an active Discord, and community-contributed components are part of the catalogue. That matters for the same reason it matters in any dependency: the project has a life beyond one maintainer's interest, though a catalogue of this kind is not the same as a critical dependency with a foundation behind it.

How teams use Magic UI

The loop that works, and the four places it goes wrong.
  1. Split the app UI from the marketing surface before you adopt anything

    The single most common mistake is installing an animated catalogue and then trying to build product screens with it. Use a primitives library for the application — accessible controls, tables, dialogs — and keep these components for the pages whose job is persuasion. They are different registers, and a dashboard with a shine border is a design failure rather than a flourish.

  2. Browse the catalogue and choose on taste before writing any code

    The three catalogues in this space are similar in mechanism and quite different in temperament, and the difference only shows up when a page is nearly finished and something feels off. Look at the previews first and pick the one whose defaults you would not need to fight — the technical integration cost is nearly identical, so taste is the only real variable.

  3. Add components through the documented path rather than copying from the preview

    Install the documented dependencies once — Tailwind, the motion library and any shared utilities — and then add components as the documentation describes. Copying markup out of a rendered preview is the shortcut that produces a page which works in isolation and then collides with your existing Tailwind configuration, your animation version or your dark-mode approach.

  4. Impose your own tokens on top of the pasted components

    Because there is no theme layer, every component arrives with its own colours and spacing. Spend twenty minutes mapping them to your existing design tokens before you have ten of them, not after: retrofitting a palette across components that have each been adjusted by hand is the kind of work nobody volunteers for, and it is the main way a page assembled from a catalogue starts looking assembled.

  5. Test the motion on a real phone and with reduced motion enabled

    Animation that reads as elegant on a desktop monitor can be a battery drain and a jank source on a mid-range Android, and a meaningful share of visitors have asked their operating system for less motion. Check both before launch — the components generally respect the reduced-motion preference, but verifying it takes a minute and finding out from a user takes longer.

  6. Record what you paste in, and revisit deliberately

    Copied source is not updated by anyone. A short note of which components came from the catalogue and when they were taken turns an eventual upgrade from an archaeology project into an afternoon, and it is the only real answer to the one genuine cost of owning your components instead of installing them.

Who Magic UI is for

The teams and moments the library actually maps onto.
  • Solo builders and small teams shipping a landing page

    The clearest fit is one to three people building a product site who need it to look like a funded company's, and who have neither a designer nor the appetite for a subscription in front of a page they are still iterating. The free catalogue is the whole reason this works: you can build the entire marketing surface, commercially, without paying for it or accepting a licence that switches off later.

  • React teams already committed to Tailwind

    If the stack is React, TypeScript, Tailwind and an animation library, adoption is close to free — add the shared utilities, paste a component, adjust it. If the stack is anything else, the answer is a different library: this is not a project that translates across frameworks, and trying to port components to another ecosystem costs more than building them.

  • Developers who want motion but not a motion career

    Getting animation to feel right is a specialism, and most front-end developers have better uses for their time than mastering springs and easing curves. Handing over components whose defaults already feel considered is a genuine shortcut, and because the source is in your repository you can still tune the details when a specific page needs it.

  • Teams whose marketing pages keep getting rebuilt

    If your organisation rebuilds the same hero, social-proof strip and pricing block every few months, the paid section and template tier addresses that specific waste — not by making the work disappear, but by starting from a finished layout instead of a blank file. It is the one case where a product explicitly aimed at individuals is still the right purchase for a company.

  • Open-source and side projects with no design budget

    An MIT-licensed catalogue with commercial use permitted and no attribution requirement is unusually generous for this space, and it makes a serious-looking project page achievable for people with no money to spend on one. That is not a soft benefit — the difference between a project that gets evaluated and one that gets closed is often the twenty minutes of polish this library supplies.

When Magic UI is the right pick

Magic UI is a good answer to a specific and slightly awkward problem: you are building a marketing surface in React, you have taste, and you do not have a designer or the weeks it would take to build motion from scratch. The library solves that by handing over components that already look considered — a marquee that moves properly, a bento grid with the right rhythm, a beam effect that reads as deliberate rather than decorative. Because they are copied into your repository, you can also make them behave the way your product needs instead of accepting an API's opinion, which matters more than it sounds: the animation is usually the part you want to adjust last, and the parts you want to adjust are always the ones a closed component will not let you reach. The reasons it is the wrong tool are equally clear. It is not an application component library, and anyone who installs it hoping for accessible dialogs, tables or form controls will be disappointed quickly — the correct pattern is a primitives library for the product and one of these catalogues for the marketing surface, and they coexist happily. It is not a design system: there are no tokens, no theming strategy and no governance, so a team with more than a couple of developers on the front end will need to impose those themselves or the pasted components will drift apart. And it is not free of maintenance. Every component you paste is a piece of code you now own, which is the whole point and also the responsibility. The test worth applying before adopting it is narrow and concrete: open the components page, look at the effects, and ask whether you would actually ship them. These three catalogues differ far more in taste than in technology, and taste is the thing you cannot refactor later without rebuilding the page.

Platform and licensing notes

What it is, what it will not do, and the facts worth verifying at the source.
A React and Tailwind component catalogue, distributed as source
Components are copied into your repository following the conventions of the primitives library this is designed to sit beside, rather than installed as a versioned dependency. That gives you full editability and removes any upstream ability to break your build — and it also means there is no upgrade path, no changelog applying to your code, and no guarantee that a fix has reached you.
A free MIT-licensed library with a separate one-time paid tier
The component library is free and MIT-licensed for commercial use. The paid product is a distinct licence covering page sections and templates, bought once at an individual tier with lifetime access and updates, and its terms prohibit reselling the code itself. No subscription is involved anywhere in the stack, which is the clearest structural difference from the closest alternative.
An animation library is a required part of the stack
The components are built on a third-party motion library, so adopting the catalogue means adopting that dependency and carrying its weight in your bundle. It is a widely used and well-maintained library, and it is still a real cost: on a page that would otherwise be static, the animation layer is the single largest thing you add.
Not an application component set, and not accessible by default
There are no form controls, data tables, dialogs or navigation primitives here, and the animated pieces are presentation-focused rather than built to a formal accessibility standard. Combining a primitives library for the application with this catalogue for the marketing surface is the pattern that works; treating either as a replacement for the other is where projects get into trouble.
Where the code lives and who maintains it
The project is developed in public under an MIT licence with a large star count, a documented contribution process and a community Discord, and community-contributed components are included. That is a healthy open-source project, and it is still a catalogue maintained largely by one author and their contributors rather than a vendor with a support contract — worth knowing before you build a launch on it.
What it does not do
It does not provide a design system, tokens or theming, so visual consistency across a team is your responsibility rather than the library's. It does not manage versions for you. It does not support frameworks or styling approaches other than the one it is built for. And it does not replace a designer: the components supply polish, not direction, and a page assembled without a point of view still reads as assembled.

Frequently Asked Questions

Quick answers about this tool—open a question to read more.