Build more with less assembly
178 Basic components cover reusable building blocks. 215 Combined patterns give you ready-made product structures such as dashboards, authentication, commerce, community, admin, portals, workflows and website sections.
FG UI is built around a simple idea: you should be able to create polished websites and applications quickly without handing your interface over to a heavy framework, a remote service or a pile of dependencies.
Every layout, component, interaction, icon and interface pattern on this website is powered by FG UI itself. No Bootstrap, Tailwind or external UI framework is used.
You get a large, coherent interface system that is straightforward to use, local to your project and ready for real product work.
178 Basic components cover reusable building blocks. 215 Combined patterns give you ready-made product structures such as dashboards, authentication, commerce, community, admin, portals, workflows and website sections.
CSS, JavaScript, icons and the default Manrope font can all run locally. FG UI does not require a CDN or a remote UI service just to render your interface.
There is no framework syntax to learn before you can make a button, card, form, dashboard or website. Load FG UI and use its classes.
FG UI 1.1.0 passed the complete 393-family automated release gate plus manual Firefox, Safari, iPhone, Android and NVDA validation, with keyboard, focus, ARIA, reduced-motion and forced-colour work in the core.
The system is designed to scale from narrow mobile widths through desktop layouts without requiring a second mobile component library.
Typography, spacing, states, borders, shadows, controls and component behaviour come from one system, so different parts of a product feel related.
FG UI is designed to give you a complete interface system without quietly adding a second stack behind your own. The comparison below describes common patterns you may encounter in dependency-heavy UI setups. Not every other toolkit works the same way.
The package declares zero runtime dependencies.
Framework-specific UI stacks can add runtime libraries or supporting packages.
FG UI can run entirely from assets hosted with your own project.
CDNs, hosted fonts, icon services or remote scripts are common choices in some stacks.
Your interface does not need a third-party CDN to render.
Some setups load framework, font or icon assets from a third-party CDN.
Six WOFF2 subsets are packaged locally, and you can opt not to use the FG UI font.
You may need to source, host or remotely load a font yourself.
The complete stable icon sprite is supplied with the kit.
An icon package, hosted icon library or separate service may need to be added.
FG UI itself does not add browser storage just to provide the interface system.
Hosted tooling, analytics or companion services can introduce additional browser storage.
FG UI does not phone home, send telemetry or track your users.
Hosted services and add-ons can add telemetry or analytics depending on how they are configured.
Copy the assets, load the CSS and JavaScript, and start using normal HTML.
Some component systems expect npm, a bundler, compilation or framework tooling before you begin.
Use familiar HTML, CSS classes and a small public JavaScript API.
Components can be tied to a particular rendering framework, syntax or project structure.
Dashboards, authentication, commerce, community, admin, portal, workflow and website patterns sit alongside 178 Basic components.
Some libraries focus mostly on primitives, leaving larger product structures for you to assemble.
Mobile behaviour is part of the same component system rather than a separate library.
Responsive coverage and mobile behaviour can vary between libraries and individual components.
Keyboard patterns, focus management, ARIA synchronisation, reduced motion and forced-colours behaviour are part of the release gates.
Accessibility support can range from strong built-in behaviour to work the implementer must add.
The browser-support policy explicitly tests no-JavaScript fallback behaviour.
Framework-rendered interfaces may have less useful content before or without their JavaScript runtime.
FGUI.init(root), multiple instances, nested components and dynamic DOM behaviour are part of the reliability gates.
Dynamic content may require framework-specific mounting, hydration or lifecycle handling.
Change shared brand tokens such as --fgui-primary without forking hundreds of component selectors.
Customisation may use variables, configuration, recompilation or component-level overrides.
FG UI 1.2.0 preserves the complete 1.1 compatibility baseline. Published stable archives are immutable; breaking contract changes require a major release.
Upgrade guarantees, deprecation windows and archive immutability differ between products.
When you self-host the supplied runtime assets, your product does not depend on fgui.forgoodtools.com being online.
Any runtime asset or service loaded from elsewhere becomes another availability dependency.
FG UI does not claim that a toolkit alone makes every website faster. What it does give you is a cleaner performance starting point: no required third-party runtime requests, no framework dependency chain, and local fonts and icons. Your final speed still depends on your own pages, media, server and implementation.
FG UI is intentionally boring in the best possible way. It provides interface code and assets, then stays out of your users' data.
The Stable core contains no required fetch, XMLHttpRequest, WebSocket, EventSource or beacon traffic. Your interface does not need to contact ForGoodTools to work.
The FG UI core does not set cookies, localStorage or sessionStorage. Features you build can use storage if you choose, but the toolkit does not add it for you.
There is no analytics beacon, usage reporting or hidden telemetry in the Stable runtime.
Manrope and the complete SVG icon sprite are bundled with FG UI, so you do not need a third-party font or icon service.
A package manager or build system can still be part of your own workflow, but FG UI does not require one before you can build a page.
FG UI targets modern evergreen browsers and does not ship a legacy-browser compatibility bundle you do not need.
Once the FG UI assets are inside your project, the runtime can be served from your own infrastructure. There is no licence check, remote UI renderer, hosted font dependency or icon API required just to draw the interface.
A UI kit is easy to make look impressive in one screenshot. The harder job is keeping it predictable when your application grows, content changes and updates arrive.
FGUI.init(root) is designed for interfaces added after page load, including CMS and application workflows.
Release gates cover multiple instances and nested components, not only isolated single-component demos.
Content Security Policy behaviour is included in the JavaScript reliability gates used for the Stable release.
The public runtime includes locale and translation helpers alongside dedicated localisation guidance.
No-JavaScript testing checks that readable content and native controls remain usable where an interaction can reasonably degrade.
Patch releases fix compatible defects, minor releases add backwards-compatible features, and breaking contracts require a major version.
Start with a Basic component when you need a small piece, or a Combined component when you need a larger ready-made area.
Use familiar HTML classes rather than learning a separate rendering framework first.
Change the content, connect your data and compose screens while keeping the core design language consistent.
This site is built with FG UI itself. The navigation, page layouts, cards, forms, menus, modals, status elements, icons and responsive behaviour are the same system the site is explaining.