8 Open-Source Projects I Use to Build Access Free Tools

Quick answer

The most useful open-source tools are not always the newest ones. They are the ones that do a clear job and let me check the result. Astro builds the pages. React runs the interactive calculators. TypeScript catches mistakes. Playwright and Vitest judge the work. Tesseract.js and Transformers.js power specific browser tools. Ollama is an optional route for questions that need a language model.

None of them replaces the part where I open the page and ask whether a normal person can use it. They make that check faster and more repeatable.

What is actually used, and where

I separate the stack into three jobs. That matters because saying a project is "used by the site" can hide a lot of detail.

Astro 7 keeps a large utility site understandable

Source: Astro on GitHub

Access Free Tools has hundreds of calculator, converter, guide, category, gallery, sitemap, and API routes. Astro gives me normal HTML for the content while still supporting server routes where the site needs them. The production build runs with the Astro Node adapter on Node 24.

The useful part for search is simple: the title, explanation, links, and examples exist in rendered HTML. A crawler does not need to press a button before it can understand what the page is about. I still have to keep sitemap and canonical rules clean. Astro does not make those decisions for me.

React 19 runs the parts people touch

Source: React documentation

The page around a calculator can stay plain HTML, while React handles the inputs, modes, results, undo buttons, and live status inside the tool. That split is useful. Someone can read the formula and example before JavaScript finishes loading, then use the interactive part when it is ready.

React also makes it easy to build too much. I watch the JavaScript budget and keep special libraries away from unrelated pages. A mortgage calculator should not download an OCR model, and a text counter should not carry game code.

TypeScript 7 catches mistakes before a visitor does

Source: Microsoft's TypeScript 7 announcement

A calculator result can look believable even when one field is wired to the wrong unit. TypeScript helps catch mismatched values and missing cases before the code reaches the browser. This project uses the fast TypeScript 7 command-line checker and keeps TypeScript 6 available for code that still needs the older compiler API.

Types are a fence, not a proof. A perfectly typed interest formula can still use the wrong assumption. I pair type checks with examples and result tests because the number matters more than the neatness of the code.

Playwright and Vitest act as two different judges

Sources: Playwrightand Vitest

Vitest checks the small logic: a legal Four in a Row move, a routing decision, an indexation rule, or a cleanup denylist. Playwright opens real pages. It can catch a heading that collides with its source note at 390 pixels wide even though the source code looks fine.

I now test editorial articles at four widths: 1440, 1024, 768, and 390 pixels. That does not prove every phone will be perfect, but it catches the sort of overlap that readers notice in one second.

Tesseract.js and Transformers.js stay on the pages that need them

Sources: Tesseract.jsand Transformers.js

The Image to Text OCR Tool loads Tesseract.js when someone starts an OCR job. Other browser AI tools can load Transformers.js for a matching model. Both libraries are imported dynamically, so ordinary calculator pages do not request those larger assets.

The limit is important. OCR still struggles with blur, glare, tiny text, odd crops, and the wrong language choice. A model can also misread context. I tell readers to check names, totals, dates, and anything important against the original image.

Ollama is optional, while calculator answers stay deterministic

Source: Ollama on GitHub

Access Free Tools can use Ollama as an optional language-model route for supported questions. I do not ask a model to invent calculator math. Exact tool answers come from the same deterministic code used by the calculator, API, and MCP routes.

That boundary is one of the most useful design decisions in the project. A model can help understand a request, but the calculation still has a repeatable input and output. If Ollama is unavailable, the supported parser route can still handle exact tool questions.

Three projects I am watching, not claiming to use

Sources: Ladybird,Lightpanda, andOpen WebUI

Ladybird is building an independent browser engine. Lightpanda is aimed at browser automation and headless work. Open WebUI provides a self-hosted interface for model workflows. Those are interesting directions, but none is a production dependency of Access Free Tools today.

The How-To Geek list also included Continue. Its official site now says the project was acquired by Cursor. That is a good reminder to recheck a project before repeating an old recommendation. Open source moves quickly, including the ownership and maintenance story.

What changed since my AI skills article

My earlier article covered free AI skills I was testing for research, writing, design, and site memory. This article looks one layer lower. These are the projects that build the pages, run the interactive pieces, check the output, or support a specific AI feature.

My rule is still the same in practice: inspect the source, give the project one clear job, keep its limits visible, and test the page a reader actually receives. A long dependency list is not progress by itself.

The practical takeaway

If you are building a small website, start with the problem you need to solve. Choose a framework because it fits the pages. Add browser automation because visual mistakes escape code review. Add an AI library only when a page has a real AI job.

Then check the project before installing it. That is the next part of this series: the repository, license, scripts, dependencies, write locations, and stop signs I review before I let an installer near this codebase.