Web Development - freeCodeCamp.org

How to Implement Role-Based Access Control in a Node.js REST API with JWT

Zia Ullah — Thu, 09 Jul 2026 14:46:47 +0000

The first time I built an API without thinking about roles, I gave every logged-in user the same access. It worked fine until a regular user accidentally hit a delete endpoint and wiped test data. That was the day I actually sat down and learned RBAC properly.

Role-Based Access Control sounds fancy, but the idea is simple: what you can do depends on who you are, not just that you're logged in. An admin deletes users. An editor creates posts. A regular user just reads. Same app, completely different experience depending on who's asking.

That's what we're building here. A REST API with three roles: JWT to carry those roles on every request, and a pair of middleware functions that check permissions before your route handlers even run. There's no database hit per request, and no if/else soup in your business logic.

By the end, you'll have three working roles (admin, editor, user) each locked to their own endpoints. More importantly, the pattern is transferable: once it clicks, you'll wire it into your next project without needing a tutorial.

Full source code on GitHub: github.com/ziaongit/nodejs-rbac-jwt-api

What You'll Learn
Prerequisites
What We'll Build
Project Setup
Setting Up the In-Memory Data Store
Building the Auth Routes
Building the RBAC Middleware
Building the Protected Routes
Putting It All Together
Testing the API
Key Takeaways
Conclusion

What You'll Learn

What RBAC is and how it differs from basic authentication
How to embed roles in JWT payloads
How to write reusable Express middleware for token verification and role checking
How to protect API routes based on user roles

Prerequisites

Node.js (v18+) installed
Basic knowledge of Express.js
Familiarity with how JWTs work (we'll cover the relevant parts)
npm installed

What We'll Build

We'll build a REST API for a simple content management system with three user roles:

Role	Permissions
`user`	Read content
`editor`	Read + create content
`admin`	Full access — read, create, delete content, manage users

The API will expose these endpoints:

Method	Endpoint	Access
POST	/api/auth/register	Public
POST	/api/auth/login	Public
GET	/api/content	user, editor, admin
POST	/api/content	editor, admin
DELETE	/api/content/:id	admin only
GET	/api/admin/users	admin only

Project Setup

Create a new folder and initialize the project:

mkdir nodejs-rbac-jwt-api
cd nodejs-rbac-jwt-api
npm init -y

Install the dependencies:

npm install express jsonwebtoken bcryptjs dotenv
npm install --save-dev nodemon

Here's what each package does:

express: web framework for building the API
jsonwebtoken: creates and verifies JWTs
bcryptjs: securely hashes passwords
dotenv: reads your .env file so you're not hardcoding secrets in your source code

Update package.json to add start scripts:

"scripts": {
  "start": "node src/app.js",
  "dev": "nodemon src/app.js"
}

Create the project structure:

nodejs-rbac-jwt-api/
├── src/
│   ├── middleware/
│   │   └── auth.js
│   ├── routes/
│   │   ├── auth.js
│   │   ├── content.js
│   │   └── admin.js
│   ├── data/
│   │   └── users.js
│   └── app.js
├── .env
├── .env.example
└── package.json

Create your .env file:

JWT_SECRET=your_super_secret_key_change_this_in_production
PORT=3000

Important: Never commit your .env file to version control. Add it to .gitignore.

Setting Up the In-Memory Data Store

We don't have a database here, just an array in memory. The point was to keep the focus on RBAC, not spend half the tutorial on database config. In a real project, swap the array for whatever database you're already using.

Create src/data/users.js:

// In-memory users store
// In production, replace this with a real database (MongoDB, PostgreSQL, etc.)
const users = [];

const findUserByEmail = (email) => users.find((u) => u.email === email);
const findUserById = (id) => users.find((u) => u.id === id);
const createUser = (user) => {
  users.push(user);
  return user;
};
const getAllUsers = () => users.map(({ password, ...user }) => user);

module.exports = { findUserByEmail, findUserById, createUser, getAllUsers };

One thing worth noting: getAllUsers uses destructuring to drop the password before returning anything. Never send password fields in API responses, even hashed ones.

Building the Auth Routes

The auth routes handle registration and login. Login is where roles first enter the picture — we embed the user's role directly into the JWT payload.

Create src/routes/auth.js:

const express = require('express');
const bcrypt = require('bcryptjs');
const jwt = require('jsonwebtoken');
const { findUserByEmail, createUser } = require('../data/users');

const router = express.Router();

// POST /api/auth/register
router.post('/register', async (req, res) => {
  const { name, email, password, role } = req.body;

  if (!name || !email || !password) {
    return res.status(400).json({ message: 'Name, email, and password are required' });
  }

  if (findUserByEmail(email)) {
    return res.status(409).json({ message: 'Email already registered' });
  }

  // Only allow valid roles — default to 'user' if none provided
  const validRoles = ['user', 'editor', 'admin'];
  const assignedRole = validRoles.includes(role) ? role : 'user';

  const hashedPassword = await bcrypt.hash(password, 10);

  const newUser = {
    id: Date.now().toString(),
    name,
    email,
    password: hashedPassword,
    role: assignedRole,
  };

  createUser(newUser);

  res.status(201).json({
    message: 'User registered successfully',
    user: {
      id: newUser.id,
      name: newUser.name,
      email: newUser.email,
      role: newUser.role,
    },
  });
});

// POST /api/auth/login
router.post('/login', async (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({ message: 'Email and password are required' });
  }

  const user = findUserByEmail(email);
  if (!user) {
    return res.status(401).json({ message: 'Invalid credentials' });
  }

  const isMatch = await bcrypt.compare(password, user.password);
  if (!isMatch) {
    return res.status(401).json({ message: 'Invalid credentials' });
  }

  // Issue JWT — embed role in the payload
  const token = jwt.sign(
    {
      id: user.id,
      email: user.email,
      role: user.role,   // ← This is the key part for RBAC
    },
    process.env.JWT_SECRET,
    { expiresIn: '24h' }
  );

  res.json({
    message: 'Login successful',
    token,
  });
});

module.exports = router;

The most important line is the JWT payload:

jwt.sign({ id, email, role }, process.env.JWT_SECRET, { expiresIn: '24h' })

By embedding role in the token, every subsequent request carries the user's permissions without requiring a database lookup. The server just verifies the token and reads the role from the payload.

Building the RBAC Middleware

This is the core of the system. We need two separate middleware functions:

verifyToken confirms the JWT is valid and attaches the decoded payload to req.user
checkRole confirms the user has the required role for a specific route

Keeping them separate gives you flexibility. Some routes only need authentication. Others need both authentication and a specific role.

Create src/middleware/auth.js:

const jwt = require('jsonwebtoken');

// Middleware 1: Verify the JWT token
const verifyToken = (req, res, next) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1]; // Expects: Bearer 

  if (!token) {
    return res.status(401).json({ message: 'Access denied. No token provided.' });
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded; // Attach decoded payload (including role) to request
    next();
  } catch (err) {
    return res.status(403).json({ message: 'Invalid or expired token.' });
  }
};

// Middleware 2: Check if user has one of the required roles
const checkRole = (...allowedRoles) => {
  return (req, res, next) => {
    if (!req.user) {
      return res.status(401).json({ message: 'Not authenticated.' });
    }

    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({
        message: `Access denied. Required role: ${allowedRoles.join(' or ')}. Your role: ${req.user.role}`,
      });
    }

    next();
  };
};

module.exports = { verifyToken, checkRole };

checkRole uses a rest parameter (...allowedRoles) so you can pass in one or multiple roles:

checkRole('admin')                  // only admin
checkRole('editor', 'admin')        // editor or admin
checkRole('user', 'editor', 'admin') // all roles

This makes route definitions clean and readable — the permissions are visible right at the route level.

Building the Protected Routes

Now let's wire up routes that use the middleware.

Create src/routes/content.js:

const express = require('express');
const { verifyToken, checkRole } = require('../middleware/auth');

const router = express.Router();

// In-memory content store
const content = [
  { id: '1', title: 'Getting Started with Node.js', author: 'admin' },
  { id: '2', title: 'Express Middleware Explained', author: 'editor' },
];

// GET /api/content — all authenticated users
router.get('/', verifyToken, checkRole('user', 'editor', 'admin'), (req, res) => {
  res.json({ content });
});

// POST /api/content — editors and admins only
router.post('/', verifyToken, checkRole('editor', 'admin'), (req, res) => {
  const { title } = req.body;

  if (!title) {
    return res.status(400).json({ message: 'Title is required' });
  }

  const newItem = {
    id: Date.now().toString(),
    title,
    author: req.user.email,
  };

  content.push(newItem);
  res.status(201).json({ message: 'Content created', item: newItem });
});

// DELETE /api/content/:id — admin only
router.delete('/:id', verifyToken, checkRole('admin'), (req, res) => {
  const index = content.findIndex((c) => c.id === req.params.id);

  if (index === -1) {
    return res.status(404).json({ message: 'Content not found' });
  }

  content.splice(index, 1);
  res.json({ message: 'Content deleted successfully' });
});

module.exports = router;

Notice how readable each route is:

router.delete('/:id', verifyToken, checkRole('admin'), handler)

You can understand the access control without reading the handler body. This is one of the key advantages of middleware-based RBAC: permissions live at the routing layer, not buried in business logic.

Create src/routes/admin.js:

const express = require('express');
const { verifyToken, checkRole } = require('../middleware/auth');
const { getAllUsers } = require('../data/users');

const router = express.Router();

// GET /api/admin/users — admin only
router.get('/users', verifyToken, checkRole('admin'), (req, res) => {
  res.json({ users: getAllUsers() });
});

module.exports = router;

Putting It All Together

Create src/app.js:

require('dotenv').config();
const express = require('express');

const authRoutes = require('./routes/auth');
const contentRoutes = require('./routes/content');
const adminRoutes = require('./routes/admin');

const app = express();

app.use(express.json());

// Routes
app.use('/api/auth', authRoutes);
app.use('/api/content', contentRoutes);
app.use('/api/admin', adminRoutes);

// Health check
app.get('/', (req, res) => {
  res.json({ message: 'RBAC API is running' });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Testing the API

Start the server:

npm run dev

Step 1: Register Users with Different Roles

curl -X POST http://localhost:3000/api/auth/register \
  -H "Content-Type: application/json" \
  -d '{"name": "Admin User", "email": "admin@example.com", "password": "password123", "role": "admin"}'

curl -X POST http://localhost:3000/api/auth/register \
  -H "Content-Type: application/json" \
  -d '{"name": "Editor User", "email": "editor@example.com", "password": "password123", "role": "editor"}'

curl -X POST http://localhost:3000/api/auth/register \
  -H "Content-Type: application/json" \
  -d '{"name": "Regular User", "email": "user@example.com", "password": "password123"}'

Step 2: Log in and Get a Token

curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com", "password": "password123"}'

You'll get a response like:

{
  "message": "Login successful",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Copy the token.

Step 3: Test Role-based Access

Read content as a regular user (should succeed):

curl http://localhost:3000/api/content \
  -H "Authorization: Bearer YOUR_TOKEN_HERE"

Try creating content as a regular user (should fail — 403):

curl -X POST http://localhost:3000/api/content \
  -H "Authorization: Bearer YOUR_TOKEN_HERE" \
  -H "Content-Type: application/json" \
  -d '{"title": "New Article"}'

Response:

{
  "message": "Access denied. Required role: editor or admin. Your role: user"
}

Now log in as an editor and try the same POST request. It succeeds. Log in as admin and try the DELETE route. Only the admin token will work.

Step 4: Decode the JWT to See the Role

You can paste any token into jwt.io to inspect the payload. You'll see something like:

{
  "id": "1720300000000",
  "email": "admin@example.com",
  "role": "admin",
  "iat": 1720300000,
  "exp": 1720386400
}

The role field is exactly what checkRole reads on every protected request.

Key Takeaways

Roles live in the JWT payload. The role travels with the token — no extra DB call needed every time someone hits a protected route. It gets embedded at login and verified cryptographically on each request.

Middleware is composable. verifyToken and checkRole are separate, reusable functions. You can chain them on any route in any combination.

Permissions are visible at the route level. router.delete('/:id', verifyToken, checkRole('admin'), handler) tells you everything about access control before you even read the handler.

Before you ship this to production:

The in-memory array was just to keep this tutorial focused — replace it with a real database before anything goes near production. A server restart wipes all your users right now.
That 24h token expiry is too long. Cut it to 15 minutes and add refresh token rotation. A stolen token becomes useless fast.
Re-validate roles from the DB on sensitive operations. A role change won't reflect in an existing token until it expires
HTTPS, always
If your permission logic grows beyond "check a role", look at casl. It handles attribute-level rules cleanly

Conclusion

The core of it fits in two middleware functions and a JWT payload. I've used this same pattern across several projects. And once you've built it yourself, you'll start spotting it everywhere, because almost every multi-user app needs some version of it.

Full source code on GitHub: github.com/ziaongit/nodejs-rbac-jwt-api

How to Build a Browser-Based PDF OCR to Text Converter Using JavaScript

Bhavin Sheth — Tue, 07 Jul 2026 16:23:22 +0000

Not every PDF contains searchable or editable text. Many PDFs are simply scanned images of documents such as invoices, contracts, books, receipts, government forms, and handwritten notes.

While these documents are easy to read, copying, searching, or editing their content isn't possible without additional processing.

This is where Optical Character Recognition (OCR) comes in. OCR recognizes text inside scanned images and converts it into editable, searchable digital text.

In this tutorial, you'll build a browser-based PDF OCR to Text Converter using JavaScript. Users will be able to upload PDF files, preview pages, configure OCR settings, extract text, monitor processing progress, review OCR confidence scores, and export the results – all directly inside the browser.

Since everything runs locally, uploaded documents never leave the user's device, making the tool both fast and privacy-friendly.

By the end of this tutorial, you'll understand how browser-based OCR works and how to build your own PDF-to-text converter using JavaScript.

Why PDF OCR Is Useful
How PDF OCR Works
Project Setup
What Libraries Are We Using?
Creating the Upload Interface
Previewing Uploaded PDF Pages
Configuring OCR Settings
Extracting Text from the PDF
Tracking OCR Progress
Understanding OCR Confidence Scores
Reviewing the Extracted Text
Exporting the OCR Results
Demo: How the PDF OCR Tool Works
Performance Optimization Tips
Important Notes from Real-World Use
Common Mistakes to Avoid
Conclusion

Why PDF OCR Is Useful

Many PDF files are scanned documents rather than digital text. Although they look readable, the text is actually stored as images, making it impossible to search, copy, edit, or analyze the content.

OCR (Optical Character Recognition) solves this problem by recognizing characters from scanned pages and converting them into editable, searchable text. Once the text is extracted, it can be copied, translated, indexed, summarized, or imported into other applications.

OCR is widely used across many industries. Businesses use it to process invoices, purchase orders, receipts, contracts, bank statements, and tax documents without manually entering data. Legal professionals use OCR to search agreements, affidavits, and court documents for names, dates, or specific clauses. Government agencies digitize historical records, application forms, passports, and official documents to build searchable digital archives.

Educational institutions convert scanned books, research papers, lecture notes, and examination materials into searchable text, making learning resources easier to access. Healthcare organizations use OCR to digitize prescriptions, laboratory reports, insurance claims, and patient records, reducing paperwork and improving record management.

OCR is also valuable for e-commerce businesses. Sellers handling hundreds of invoices, shipping labels, and purchase orders from platforms such as Amazon, Flipkart, Meesho, or Shopify can quickly extract order numbers, customer details, addresses, and product information instead of typing everything manually.

Developers use OCR when building document management systems, enterprise search tools, AI assistants, and workflow automation platforms where scanned documents need to become searchable digital content.

Since this application performs OCR entirely inside the browser, users can process confidential documents without uploading them to external servers. This keeps document processing fast, private, and secure while making scanned PDFs much more useful.

How PDF OCR Works

A PDF OCR application converts scanned pages into editable text by combining PDF rendering with Optical Character Recognition.

When a user uploads a PDF, the browser first validates the document and loads it into memory. Each page is then rendered as an image using PDF.js. These rendered page images become the input for the OCR engine.

The OCR engine examines every image pixel by pixel. It identifies printed characters, recognizes words and sentences, and reconstructs the document as digital text. Depending on the selected language, the recognition engine applies language-specific dictionaries and character models to improve accuracy.

If the user enables image enhancement, the application can improve the scanned page before recognition. Converting the page to grayscale, increasing contrast, or sharpening the image often helps OCR detect characters more accurately, especially when working with old scans or low-quality photocopies.

As each page is processed, the application updates a progress indicator so users can monitor the extraction process in real time. The OCR engine also returns a confidence score for every page, allowing users to estimate how reliable the recognized text is.

After all selected pages have been processed, the application combines the extracted text into a single document. Users can review the output, copy it directly from the browser, or export it as a TXT or JSON file for further use.

Since every stage of the workflow runs locally, the uploaded PDF never leaves the user's device. This makes browser-based OCR an excellent solution for sensitive business documents, legal records, healthcare files, financial reports, and government paperwork.

Project Setup

We'll build the PDF OCR application using standard web technologies.

Create the following project structure.

pdf-ocr-tool/

│── index.html

│── style.css

│── script.js

Next, include the required JavaScript libraries inside index.html.

These libraries provide everything needed to render PDF pages, recognize text, and manage PDF-related operations directly inside the browser.

What Libraries Are We Using?

This project combines several JavaScript libraries because OCR involves multiple processing stages.

The primary library is PDF.js, which loads the uploaded PDF document and renders every page as an image inside the browser. Since OCR engines work with images rather than PDF files directly, rendering each page is the first step of the workflow.

The application uses Tesseract.js to perform Optical Character Recognition. Tesseract is one of the most popular open-source OCR engines and supports dozens of languages, making it possible to recognize printed text from scanned documents without relying on any external API or cloud service.

We also include PDF-lib, which helps manage PDF-related operations and provides additional flexibility if future features such as annotations, metadata editing, or document modifications are added.

Together, these libraries create a complete browser-based OCR solution capable of rendering PDF pages, recognizing printed text, tracking recognition progress, reporting confidence scores, and exporting the extracted text while keeping every document private on the user's device.

Creating the Upload Interface

Every OCR workflow begins with selecting a PDF document. Before the application can recognize any text, it must first load the PDF into the browser and verify that it's a supported file type.

A good upload interface should be simple, intuitive, and accessible for both desktop and mobile users. Supporting drag-and-drop uploads alongside the traditional file picker gives users multiple ways to import their documents.

In this project, the upload section serves as the starting point for the entire OCR workflow. After a PDF is selected, the browser validates the file, reads it into memory, and prepares it for page rendering. Since the application runs completely inside the browser, no document is uploaded to an external server. This ensures confidential PDFs remain private throughout the OCR process.

The upload interface also provides clear instructions so users immediately understand how to begin using the tool.

Here's the HTML for the upload area:



    

        
            ☁
        

        Drag & Drop PDF Here

        Or click to browse file

Next, validate the uploaded file before loading it.

const pdfInput = document.getElementById("pdfInput");

pdfInput.addEventListener("change", async (event)=>{

    const file = event.target.files[0];

    if(!file) return;

    if(file.type !== "application/pdf"){

        alert("Please upload a valid PDF file.");

        return;

    }

    loadPDF(file);

});

Once the validation succeeds, the PDF is loaded into memory and the application proceeds to generate preview thumbnails for each page.

Previewing Uploaded PDF Pages

After the PDF has been loaded successfully, the application generates page previews.

Instead of immediately starting OCR, users first see thumbnail images for every page in the uploaded document. This allows them to confirm that the correct file has been selected and inspect the document before extraction begins.

The preview stage is especially useful for large PDFs because users can quickly identify scanned pages, blank pages, rotated pages, or incorrect uploads without wasting time running OCR on the wrong document.

PDF.js renders every page as a canvas before displaying it inside the preview grid.

First, load the PDF document.

const pdf = await pdfjsLib.getDocument({

    data: await file.arrayBuffer()

}).promise;

Next, render every page.

for(let pageNumber = 1; pageNumber <= pdf.numPages; pageNumber++){

    const page = await pdf.getPage(pageNumber);

    const viewport = page.getViewport({

        scale:0.35

    });

    const canvas = document.createElement("canvas");

    const context = canvas.getContext("2d");

    canvas.width = viewport.width;

    canvas.height = viewport.height;

    await page.render({

        canvasContext:context,

        viewport

    }).promise;

    previewContainer.appendChild(canvas);

}

Each rendered page becomes a thumbnail, allowing users to scroll through the document before choosing the OCR settings.

This visual confirmation greatly reduces mistakes when processing long reports, contracts, invoices, books, or multi-page scanned documents.

Configuring OCR Settings

Different PDF documents require different OCR configurations. A clean digital scan usually processes very quickly, while old photocopies or low-quality scans often require additional image enhancement to improve recognition accuracy.

Before starting OCR, the application allows users to customize several options that affect how text is extracted.

Users can choose whether OCR should process every page or only a specific page range. This is particularly useful when working with large documents where only a few pages contain important information.

The OCR engine also supports multiple recognition languages. Selecting the correct language helps improve accuracy because Tesseract uses language-specific dictionaries and character models during recognition.

For users who prioritize speed, the Fast mode completes OCR quickly while still producing good results. When working with low-quality scans or official documents, High Accuracy mode performs additional processing to improve recognition quality.

The application also includes optional image enhancement settings. Converting pages to grayscale, increasing contrast, or sharpening the scanned image often improves OCR accuracy by making printed characters easier to recognize.

These configurable options allow the OCR engine to adapt to many different document types without overwhelming users with unnecessary complexity.

The page selection section allows users to process either the entire document or only selected pages.



All Pages



Specific Pages

Users can also choose the OCR language.

Next, configure the OCR accuracy mode.

const mode = document.querySelector(

'input[name="accuracy"]:checked'

).value;

console.log(mode);

Finally, enable optional image enhancement features before OCR begins.

const grayscale = grayscaleCheckbox.checked;

const contrast = contrastCheckbox.checked;

const sharpen = sharpenCheckbox.checked;

console.log(

grayscale,

contrast,

sharpen

);

These settings allow the application to balance processing speed and recognition quality depending on the type of PDF being analyzed.

Improving OCR Accuracy Before Processing

One advantage of browser-based OCR is that the document can be optimized before recognition begins. Small image enhancements often have a significant impact on the quality of the extracted text.

For example, grayscale conversion removes unnecessary color information, allowing the OCR engine to focus only on character shapes. Increasing contrast helps distinguish text from the page background, while sharpening makes blurred letters easier to recognize.

These enhancements are especially valuable when processing old books, photocopies, historical records, receipts, handwritten forms, government documents, engineering drawings, and low-resolution scans.

Choosing the correct OCR language is equally important. A scanned Gujarati document processed using the English language model will usually produce poor recognition results. Selecting the matching language significantly improves OCR accuracy.

Taking a few moments to configure these settings before processing often produces cleaner extracted text, fewer recognition errors, and higher confidence scores, particularly when working with challenging documents.

Extracting Text from the PDF

Once the document has been uploaded, previewed, and the OCR settings have been configured, the application is ready to extract text from the selected pages.

Unlike searchable PDFs that already contain digital text, scanned PDF documents consist entirely of images. OCR works by examining each rendered page image, recognizing every visible character, and converting those characters into editable text.

The extraction process begins by rendering each selected PDF page as an image using PDF.js. Each rendered page is then passed to Tesseract.js, which analyzes the image pixel by pixel and reconstructs words, sentences, paragraphs, and punctuation.

If the user selected a specific page range, only those pages are processed. Otherwise, every page in the document is analyzed.

Because OCR can be computationally intensive, especially for high-resolution scans, the application processes one page at a time. This approach keeps memory usage lower while providing continuous progress updates to the user.

The recognized text from each page is appended to a single output document that can later be reviewed, copied, or exported.

First, create the OCR worker.

const worker = await Tesseract.createWorker(

    selectedLanguage

);

Next, loop through the selected pages.

for(let page = startPage; page <= endPage; page++){

    await processPage(page);

}

Now perform OCR on the rendered page.

const result = await worker.recognize(

    canvas

);

const extractedText = result.data.text;

Append the extracted text to the final output.

finalText +=

`----- Page ${page} -----\n\n`;

finalText += extractedText;

finalText += "\n\n";

Once every page has been processed, terminate the OCR worker.

await worker.terminate();

Processing one page at a time allows users to monitor OCR progress while ensuring stable performance, even for large documents.

Tracking OCR Progress

OCR processing can take anywhere from a few seconds to several minutes depending on the size of the document, image quality, language, and selected accuracy mode.

Providing a progress indicator is important because users can immediately see that the application is actively processing the document instead of appearing frozen.

As each page finishes recognition, the progress bar updates automatically, displaying both the current page number and the overall completion percentage.

For example, a 42-page document may display messages such as "Processing Page 2 of 42" before eventually reaching the final page.

Showing real-time progress improves the overall user experience and makes it easier to estimate the remaining processing time.

The OCR engine reports its progress while recognizing each page.

logger: info => {

    console.log(info);

}

Update the progress bar.

progressBar.style.width =

`${percentage}%`;

progressLabel.innerText =

`${percentage}%`;

Display the currently processed page.

status.innerText =

`Processing Page ${currentPage}

of ${totalPages}`;

Once the final page has been processed, the progress bar reaches one hundred percent and the extracted text becomes available for review.

Understanding OCR Confidence Scores

One useful feature of Tesseract.js is that it reports a confidence score for every page that it processes.

The confidence score estimates how accurately the OCR engine recognized the characters contained on a page. Higher confidence generally indicates cleaner scans, sharper text, and fewer recognition errors.

For example, a professionally scanned document with clear printed text may produce confidence scores above ninety-five percent, while older photocopies or blurry mobile phone images may produce lower values.

Displaying confidence scores helps users quickly identify pages that may require manual review or reprocessing.

In this application, every processed page displays its individual OCR confidence score after recognition finishes.

The OCR engine returns the confidence value together with the extracted text.

const confidence =

result.data.confidence;

Store each page's score.

confidenceScores.push({

    page: currentPage,

    confidence

});

Display the results.

confidenceScores.forEach(score=>{

    console.log(

        score.page,

        score.confidence

    );

});

Pages with lower confidence scores may contain faded text, handwritten notes, poor lighting, skewed scans, or low image resolution. Reviewing these pages helps improve the overall quality of the extracted document.

Optimizing OCR Accuracy

Even with a powerful OCR engine, the quality of the original document has a significant impact on the extracted text.

Scanned PDFs with sharp, high-resolution pages usually produce excellent results without additional processing. But documents containing faded printing, uneven lighting, shadows, handwritten annotations, or compression artifacts may require image enhancement before OCR begins.

The application includes several preprocessing options that improve recognition quality.

Grayscale conversion removes unnecessary color information and simplifies the image for the OCR engine. Increasing contrast helps separate text from the background, while sharpening improves character edges that may appear blurry in low-quality scans.

Selecting the correct recognition language is equally important. OCR models are trained for specific languages, so choosing the matching language greatly improves character recognition and reduces spelling mistakes.

Users should also select the appropriate accuracy mode. Fast Mode works well for clean digital scans, while High Accuracy Mode performs additional analysis that produces better results for difficult documents, although it requires more processing time.

Taking a few extra seconds to configure these settings often produces significantly cleaner text, higher confidence scores, and fewer manual corrections after extraction.

Reviewing the Extracted Text

Once the OCR process finishes, the application combines the recognized text from every processed page into a single output area.

Instead of immediately downloading the results, users can first review the extracted text directly inside the browser. This provides an opportunity to verify the OCR output, check formatting, identify recognition errors, and ensure that the correct pages were processed.

The extracted text preserves the page sequence by separating the content from each page with a clear page heading. This makes it much easier to navigate large documents such as books, contracts, technical manuals, invoices, government records, and research papers.

For searchable PDFs, the extracted text is usually very accurate. For scanned documents, users can quickly compare the OCR output with the original page preview and decide whether additional image enhancement or a different OCR language would improve the results.

The application also includes a Copy button so users can instantly copy all extracted text to the clipboard without downloading a file.

First, display the extracted text.

document.getElementById(

"output"

).value = finalText;

Next, implement the copy feature.

async function copyText(){

    await navigator.clipboard.writeText(

        finalText

    );

    alert("Text copied successfully.");

}

Attach the event listener.

document.getElementById(

"copyButton"

).addEventListener(

"click",

copyText

);

Providing an in-browser preview allows users to verify OCR quality before exporting the results.

Exporting the OCR Results

After reviewing the extracted content, users can export it in different formats depending on how they intend to use the information.

Plain text files are ideal for editing inside any text editor, importing into word processors, or searching with desktop applications.

JSON exports are useful for developers building document management systems, AI applications, search engines, automation workflows, or APIs that consume structured OCR results.

Providing multiple export formats makes the OCR tool suitable for both everyday users and software developers.

Creating a downloadable TXT file is straightforward.

const blob = new Blob(

    [finalText],

    {

        type:"text/plain"

    }

);

Generate the download link.

const url = URL.createObjectURL(

blob

);

const link = document.createElement(

"a"

);

link.href = url;

link.download = "ocr-output.txt";

link.click();

JSON exports include additional information such as page numbers and confidence scores.

const report = {

    text: finalText,

    confidence: confidenceScores

};

downloadJSON(report);

These export options allow users to continue working with the extracted text in virtually any application.

Demo: How the PDF OCR Tool Works

Step 1: Upload Your PDF

The OCR workflow begins by uploading a PDF document using either the drag-and-drop area or the file picker.

Once a document has been selected, the browser validates the file format, loads the PDF into memory, and prepares it for page rendering. Since all processing occurs locally, the uploaded file never leaves the user's computer.

Step 2: Preview the Uploaded PDF

After the upload is complete, the application renders thumbnail previews of every page.

This allows users to verify that the correct document has been selected and inspect the page order before running OCR.

Previewing the document is particularly useful when processing large books, reports, legal documents, or scanned archives containing dozens of pages.

Step 3: Configure OCR Settings

Before text extraction begins, users configure the OCR options.

The application allows users to choose all pages or a specific page range, select the OCR language, switch between Fast and High Accuracy modes, and enable optional image enhancement features such as grayscale conversion, contrast improvement, and sharpening.

These settings help improve recognition quality depending on the condition of the scanned document.

Step 4: Start OCR Processing

After reviewing the settings, users click the Extract Text button.

The browser begins processing every selected page one by one. During this stage, each rendered page image is analyzed by the OCR engine, which recognizes printed characters and converts them into editable text.

Because OCR runs directly inside the browser, even confidential documents remain completely private throughout the process.

Step 5: Monitor Processing Progress

As OCR runs, the application displays a live progress indicator.

Users can monitor the current page being processed, overall completion percentage, and recognition progress in real time. For large documents, this provides useful feedback and reassures users that the application is actively processing the file.

Step 6: Review OCR Confidence Scores

Once recognition is complete, the application displays confidence scores for every processed page.

These values indicate how accurately the OCR engine recognized each page. Pages with lower confidence scores may contain faded text, skewed scans, or poor image quality and can be reviewed manually if necessary.

Confidence scores provide an additional layer of quality assurance before exporting the extracted text.

Step 7: Review the Extracted Text

After OCR finishes, the complete extracted text appears inside the browser.

Users can scroll through the recognized content, compare it with the original document, and copy the text directly to the clipboard using the built-in Copy button.

This makes it easy to reuse the extracted information immediately without downloading a separate file.

Step 8: Export the Results

Finally, users can export the OCR results.

The application supports downloading the extracted text as a TXT file for general editing or as a JSON file for software development and automation workflows.

After selecting the preferred format, the browser generates the file instantly without uploading any data to external servers.

Performance Optimization Tips

OCR is one of the most computationally intensive operations performed inside a browser. Although modern JavaScript engines and OCR libraries are highly optimized, a few simple techniques can significantly improve performance.

Before processing begins, render PDF pages at an appropriate resolution. Extremely high-resolution images increase processing time without always improving recognition accuracy.

const viewport = page.getViewport({

    scale:1.5

});

Processing pages sequentially instead of loading every page simultaneously reduces memory consumption for large documents.

for(let page = 1; page <= totalPages; page++){

    await processPage(page);

}

Users should enable OCR only when working with scanned PDFs. Searchable PDFs already contain digital text, so OCR simply increases processing time without improving the results.

If the document contains hundreds of pages, allowing users to analyze only a selected page range can significantly reduce processing time.

Using grayscale images instead of full-color pages also improves recognition speed while reducing memory usage.

Whenever possible, choose the OCR language that matches the document. Smaller language models generally process faster and produce more accurate results than attempting recognition with an incorrect language.

Finally, remember to terminate the OCR worker after processing completes to release browser resources.

await worker.terminate();

These small optimizations produce a smoother user experience while making browser-based OCR practical even for large documents.

Important Notes from Real-World Use

OCR accuracy depends heavily on the quality of the original document.

Clean scans with high resolution, good lighting, and sharp printed text usually produce excellent recognition results. Older photocopies, faded documents, handwritten notes, or skewed scans may require image enhancement before OCR begins.

Before processing, always verify that the uploaded file is a valid PDF.

if(file.type !== "application/pdf"){

    alert("Please upload a valid PDF.");

    return;

}

Selecting the correct OCR language is equally important. Processing a Gujarati document with the English language model will significantly reduce recognition accuracy.

console.log(

"Selected Language:",

selectedLanguage

);

Users should also review OCR confidence scores after processing. Pages with lower confidence values often benefit from rescanning or using image enhancement options.

Because the entire workflow runs locally, browser-based OCR is well suited for confidential business reports, contracts, financial documents, legal records, healthcare files, and government paperwork that should never be uploaded to third-party services.

Common Mistakes to Avoid

One common mistake is enabling OCR for documents that already contain selectable text.

Searchable PDFs can usually be processed much faster by extracting the embedded text directly.

if(pdfHasText){

    skipOCR();

}

Another mistake is choosing the wrong recognition language.

Always select the language that matches the document before starting OCR.

worker = await Tesseract.createWorker(

selectedLanguage

);

Some users also attempt OCR on extremely low-quality scans without enabling image enhancement.

Using grayscale conversion, contrast adjustment, or sharpening often improves recognition quality considerably.

Finally, always review the extracted text before exporting it.

Checking the OCR output and confidence scores helps identify pages that may require rescanning or additional processing before the results are used in business workflows.

Conclusion

In this tutorial, you built a browser-based PDF OCR to Text Converter using JavaScript.

You learned how to upload PDF documents, preview scanned pages, configure OCR settings, select recognition languages, improve image quality, extract text, monitor processing progress, review OCR confidence scores, and export the recognized text directly from the browser.

More importantly, you discovered how modern browsers can perform Optical Character Recognition locally without requiring a backend server or cloud-based OCR service.

This approach keeps document processing fast, private, and secure while giving users complete control over how scanned PDFs are converted into editable text.

You can try the complete implementation here:

PDF OCR to Text Converter

Once you understand this workflow, you can extend the project further by adding handwriting recognition, AI-powered document summarization, automatic translation, named entity extraction, keyword detection, document classification, searchable PDF generation, or intelligent document automation.

How to Build Production-Ready Card Components with shadcn/ui

Vaibhav Gupta — Tue, 07 Jul 2026 16:00:40 +0000

Card components are one of the most common UI patterns in web development. You see them in property listing apps, SaaS analytics dashboards, e-commerce product pages, and admin panels.

But building a card that handles hover states cleanly, supports dark mode, stays accessible, and works across screen sizes takes more than wrapping content in a

. You need a consistent component structure, a reliable design system, and well-thought-out Tailwind patterns.

In this tutorial, you'll build four types of production-ready card components using shadcn/ui and Base UI primitives via Shadcn Space. Each card targets a specific, real-world UI pattern that developers run into regularly.

By the end, you'll have:

A Preview Card with a group hover image effect, an overlay arrow icon, and a property details layout
An Analytics Card with typed metric props, conditional badge colors, and a decorative background image
A Statistics Card with a responsive four-column e-commerce stats grid and icon badges
An Ecommerce Product Variant Card with size selection, a wishlist toggle, a bag button, and a ripple animation on the buy button

Prerequisites
Why shadcn/ui?
What is Shadcn Space?
What You'll Build
How to Set Up the CLI Registry
How to Build the Preview Card (card-02)
Live Preview
How to Build the Analytics Card (card-05)
Live Preview
How to Build the Statistics Card (card-06)
Live Preview
How to Build the Ecommerce Product Variant Card (card-17)
Live Preview
Quick Reference Table
Key Concepts Recap
Conclusion
Resources

Prerequisites

Before you start, make sure you have the following in place:

Node.js 18 or higher installed
A Next.js or React project set up
shadcn/ui initialized in your project (npx shadcn@latest init)
Tailwind CSS configured
Basic knowledge of React and TypeScript

If you haven't initialized shadcn/ui yet, run npx shadcn@latest init in your project root and follow the prompts before continuing.

Why shadcn/ui?

shadcn/ui is a collection of accessible, open-source React components built on top of Radix UI, Base UI, and styled with Tailwind CSS.

The way it works is different from a traditional component library. Instead of installing a package, you use a CLI to copy the component source files directly into your project. This means you own every line of the code. You can read it, edit it, and the component will never break because of a library update you didn't control.

Some key benefits:

Accessible by default: built on Radix UI and Base UI primitives
Fully Tailwind-based: no external CSS files, no specificity conflicts
Zero lock-in: components live in your components/ folder, not inside node_modules
Works everywhere: Next.js, Vite, Astro, Remix, and other React frameworks

The Card, Badge, Button, and Separator components you'll use in this tutorial all come from the shadcn/ui base install.

What is Shadcn Space?

Shadcn Space is an open-source registry of production-ready components and UI blocks built on top of shadcn/ui. It extends the default shadcn/ui component set with additional variants from common patterns to highly appealing layouts.

The key difference from the default shadcn/ui Card component is that Shadcn Space cards are designed for specific layout patterns. You get more structure out of the box.

Each component in Shadcn Space supports both Radix UI and Base UI primitives. You also get the functionality of Copy Prompt. This tutorial uses the Base UI versions. You install them the same way as any shadcn/ui component, through a single CLI command, and the source files land in your project.

You can browse the full card collection in the Shadcn card component library.

What You'll Build

Here's an overview of the four cards you'll build, along with their specific features:

Preview Card (card-02)

Large image with hover brightness and scale animation
An arrow icon that appears only on hover
Property title and location
Price badge with a teal color scheme
Amenity row with bed, bath, and area icons

Analytics Card (card-05)

Typed TypeScript props with a built-in default dataset
Two metric columns separated by a vertical divider
Conditional badge colors based on positive or negative trend
Decorative background image pinned to the bottom-right corner

Statistics Card (card-06)

Four-column responsive grid that stacks on mobile
Iconify Solar icon set for each metric
Badge with trend direction icon
Border dividers are removed from the last column automatically

Ecommerce Product Variant Card (card-17)

Product image with 3D drop shadow and hover zoom
Wishlist heart toggle with dark mode support
Size selector with active state highlighting
Bag icon toggle that fills on click
"Buy Now" button with a CSS ripple animation
Dynamic delivery date with ordinal suffix formatting

How to Set Up the CLI Registry

Before you run any install commands, you need to register the Shadcn Space registry in your components.json file.

Open components.json in your project root and add the registries field:

{
  "registries": {
    "@shadcn-space": {
      "url": "https://shadcnspace.com/r/{name}.json"
    }
  }
}

This tells the shadcn CLI where to find components prefixed with @shadcn-space/. Without this step, all the install commands in this tutorial will fail.

Your full components.json should look something like this after adding the registry:

{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "default",
  "rsc": true,
  "tsx": true,
  "tailwind": {
    "config": "tailwind.config.ts",
    "css": "app/globals.css",
    "baseColor": "neutral",
    "cssVariables": true
  },
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils"
  },
  "registries": {
    "@shadcn-space": {
      "url": "https://shadcnspace.com/r/{name}.json"
    }
  }
}

For a full walkthrough of how the CLI works with third-party registries, visit the getting started guide. You can also watch the video walkthrough if you prefer to follow along visually.

How to Build the Preview Card (card-02)

What the Preview Card Does

The Preview Card is designed for property listings, hotel pages, or any content that benefits from a large image with supporting details below it.

When a user hovers the card, the image darkens and scales up. An arrow icon appears in the corner. Below the image, a title, location, price badge, and amenity row are displayed.

How to Install the Preview Card

Run one of the following commands based on your package manager:

npm:

npx shadcn@latest add @shadcn-space/card-02

pnpm:

pnpm dlx shadcn@latest add @shadcn-space/card-02

Yarn:

yarn dlx shadcn@latest add @shadcn-space/card-02

Bun:

bunx --bun shadcn@latest add @shadcn-space/card-02

The CLI copies the component into your project at:

components/
  shadcn-space/
    card/
      Card-02.tsx

The Component Code

import { Badge } from "@/components/ui/badge";
import { Card } from "@/components/ui/card";
import { ArrowRight, Bath, BedDouble, Expand } from "lucide-react";

const PreviewCard = () => (
  
    
      
        
          
        
      

      
        
      
    

    
      
        
          
            
              Serenity Residential Home
            
          
          
            15 S Aurora Ave, Miami
          
        

        
          $570,000
        
      

      
        
          
          5 Bedrooms
        

        
          
          3 Bathrooms
        

        
          
          
            120m²
          
        
      
    
  
);

export default PreviewCard;

Let's now go through how this code works.

1. Group hover behavior

The group class on the outer Card element is the core of this component. Any child element with a group-hover: class will respond when the card is hovered, not just that individual element.

This is how the image darkens (group-hover:brightness-50), scales up (group-hover:scale-125), and the arrow icon appears (group-hover:block).

2. Overflow clipping on image zoom

Without overflow-hidden on the image wrapper, the scale-125 transform would bleed past the card's rounded corners on hover. The wrapper clips the image so it stays inside the card boundary.

Notice that rounded-t-2xl appears on both the wrapper and the image itself to maintain a consistent corner radius during the transition.

3. Logical border properties in the amenity row

The amenity row uses border-e instead of border-r. This is a CSS logical property meaning "border at the inline end." In left-to-right layouts, that's the right side. In right-to-left layouts, it flips automatically. Using logical properties is a good production habit for any component that may need to support multiple locales.

Live Preview:

How to Build the Analytics Card (card-05)

What the Analytics Card Does

The Analytics Card is a compact dashboard widget. It shows two metrics side by side with values and percentage-change badges. A decorative chart image sits in the bottom-right corner.

The component is typed with TypeScript interfaces, making it easy to swap in real data from an API.

How to Install the Analytics Card

npx shadcn@latest add @shadcn-space/card-05

The CLI copies the component into:

components/
  shadcn-space/
    card/
      card-05.tsx

The Component Code

import { Badge } from "@/components/ui/badge";
import { Card, CardContent } from "@/components/ui/card";
import { Separator } from "@/components/ui/separator";
import { cn } from "@/lib/utils";

type DashboardMetric = {
  label: string;
  value: string;
  percentage: string;
  isPositive?: boolean;
};

type MainDashboardData = {
  title: string;
  description: string;
  metrics: DashboardMetric[];
};

type WidgetProps = {
  mainDashboard?: MainDashboardData;
};

const mainDashboardData: MainDashboardData = {
  title: "Analytics Dashboard",
  description: "Check all the statistics",
  metrics: [
    {
      label: "Earnings",
      value: "$27,850",
      percentage: "+18%",
      isPositive: true,
    },
    {
      label: "Expense",
      value: "$18,453",
      percentage: "-5%",
      isPositive: false,
    },
  ],
};

const AnalyticsCard = ({ mainDashboard = mainDashboardData }: WidgetProps) => {
  return (
    
      
        
          
            
              
                
                  {mainDashboard.title}
                
                
                  {mainDashboard.description}
                
              
              
                {mainDashboard.metrics.map((metric, index) => (
                  
                    
                      
                        {metric.label}
                      
                      
                        
                          {metric.value}
                        
                        
                          {metric.percentage}
                        
                      
                    
                    {index < mainDashboard.metrics.length - 1 && (
                      
                    )}
                  
                ))}
              
            

            
          
        
      
    
  );
};

export default AnalyticsCard;

How the Analytics Card works:

1. Optional props with a default dataset

The component accepts an optional mainDashboard prop. If you don't pass anything, it falls back to mainDashboardData, the constant is defined in the same file:

const AnalyticsCard = ({ mainDashboard = mainDashboardData }: WidgetProps) => {

This pattern lets the component work out of the box in demos or Storybook, while still being fully driven by real API data in production. To connect it to live data, you just pass a prop that matches the MainDashboardData shape.

2. Conditional badge colors with `cn()`

The cn() utility (from @/lib/utils) merges Tailwind class names and handles conditional logic cleanly. It also de-duplicates conflicting Tailwind classes automatically, which plain template literals don't do:

className={cn(
  "font-normal text-muted-foreground",
  metric.isPositive ? "bg-teal-400/10" : "bg-red-500/10"
)}

3. Separators only between metrics, not after the last one

The Separator component renders only between metrics, never after the last one. The index check handles this:

{index < mainDashboard.metrics.length - 1 && (
  
)}

4. Absolute-positioned decorative image

The chart image is used absolute bottom-0 right-0 to pin it to the card's bottom-right corner. It hides on small screens with hidden sm:block to avoid layout issues on mobile. The parent Card has relative positioning to contain it.

Live Preview:

How to Build the Statistics Card (card-06)

What the Statistics Card Does

The Statistics Card displays four e-commerce metrics in a horizontal grid: Orders, Sales, Profit, and Expense. Each column has an icon, a large value, a time period label, and a badge showing the percentage trend.

The layout is fully responsive, collapsing from four columns to two on medium screens and stacking on mobile.

This card uses @iconify/react for icons instead of lucide-react, giving you access to thousands of icon sets using string-based icon names.

How to Install the Statistics Card

First, install @iconify/react if you don't have it:

npm install @iconify/react

Then add the card component:

npx shadcn@latest add @shadcn-space/card-06

The CLI copies the component into:

components/
  shadcn-space/
    card/
      card-06.tsx

The Component Code

"use client";
import { Icon } from "@iconify/react";
import { Card, CardContent } from "@/components/ui/card";
import { Badge } from "@/components/ui/badge";

const StatisticsCard = () => {
  const EcommerceActions = [
    {
      title: "Orders",
      subtitle: "5868",
      cardIcon: "solar:bag-4-line-duotone",
      badgeColor: "bg-teal-400/10",
      statusValue: "+18%",
      statusIcon: "solar:course-up-line-duotone",
    },
    {
      title: "Sales",
      subtitle: "$96,850",
      cardIcon: "solar:box-line-duotone",
      badgeColor: "bg-orange-400/10",
      statusValue: "-5%",
      statusIcon: "solar:course-down-line-duotone",
    },
    {
      title: "Profit",
      subtitle: "$82,906",
      cardIcon: "solar:chart-square-line-duotone",
      badgeColor: "bg-teal-400/10",
      statusValue: "+18%",
      statusIcon: "solar:course-up-line-duotone",
    },
    {
      title: "Expense",
      subtitle: "$14,653",
      cardIcon: "solar:star-line-duotone",
      badgeColor: "bg-teal-400/10",
      statusValue: "+18%",
      statusIcon: "solar:course-up-line-duotone",
    },
  ];

  return (
    
      
        
          {EcommerceActions.map((item, index) => (
            
              
                
                  
                    {item.title}
                    
                      
                    
                  
                  
                    {item.subtitle}
                    
                      Last 7 days
                      
                        
                          {item.statusValue}
                          
                        
                      
                    
                  
                
              
            
          ))}
        
      
    
  );
};

export default StatisticsCard;

How the Statistics Card works:

1. Data-driven layout with an array

All four metrics live in the EcommerceActions array. Adding or removing a metric only requires updating the array. The JSX stays the same. This is the right approach for any component with a repeating structure: keep data and markup separate.

2. Responsive column widths

Each column uses three width classes to handle every breakpoint:

w-full on mobile (single column, stacked vertically)
md:w-6/12 on medium screens (two columns)
lg:w-3/12 on large screens (four equal columns)

The flex-wrap on the CardContent lets columns wrap naturally on smaller screens. lg:flex-nowrap forces them into a single row on large screens.

3. Removing the last border with `last:`

The last:border-e-0 class removes the right border from the final column. Without it, there'd be a stray border on the right edge of the card.

The last: variant is a Tailwind pseudo-class that targets the last child element in a group, which is cleaner than tracking the index manually.

4. Why `"use client"` is needed here

The @iconify/react package requires a browser environment. In Next.js with the App Router, any component that imports a client-only package needs the "use client" directive at the top of the file. Without it, the server will throw an error during rendering.

Live Preview:

How to Build the Ecommerce Product Variant Card (card-17)

What the Ecommerce Product Variant Card Does

This is the most interactive card in this tutorial. It's a product card for a shoe listing with a hover zoom, a wishlist toggle, size buttons, a bag toggle, and a ripple-animation buy button. All interactions are handled with React's useState, so no external state management library is required.

How to Install the Product Variant Card

npx shadcn@latest add @shadcn-space/card-17

The CLI copies the component into:

components/
  shadcn-space/
    card/
      card-17.tsx

The Component Code

"use client";

import { useState } from "react";
import { Card, CardContent, CardFooter } from "@/components/ui/card";
import { Button } from "@/components/ui/button";
import { Heart, ShoppingBag } from "lucide-react";
import { cn } from "@/lib/utils";

const sizes = ["7", "8", "9", "10"];

const getDeliveryDate = () => {
  const date = new Date();
  date.setDate(date.getDate() + 3);
  const day = date.getDate();
  const month = [
    "Jan", "Feb", "Mar", "Apr", "May", "Jun",
    "Jul", "Aug", "Sep", "Oct", "Nov", "Dec",
  ][date.getMonth()];
  const suffix = ["th", "st", "nd", "rd"][
    day % 10 > 3 ? 0 : (day % 100 - day % 10 !== 10 ? day % 10 : 0)
  ];
  return `${day}${suffix} ${month}`;
};

export default function EcommerceProductCard() {
  const [activeSize, setActiveSize] = useState(1);
  const [isWishlisted, setIsWishlisted] = useState(false);
  const [inBag, setInBag] = useState(false);

  return (
    
      

        {/* Image zone */}
        
          

          {/* Discount badge */}
          
            -21%
          

          {/* Wishlist button */}
          
        

        {/* Info zone */}
        
          
            Nike
            
              Air Max Pulse Running Shoes
            
          

          
            
              Down 21%
            
            $150
            $119
          

          
            Delivery by{" "}
            
              {getDeliveryDate()}
            
          

          {/* Size selector */}
          
            {sizes.map((s, i) => (
              
            ))}
          
        

        {/* Action zone */}
        
          

          
        

      
    
  );
}

How the Ecommerce Product Variant Card works:

1. Named group hover scopes

This card uses two independent hover group scopes: group/card on the outer card and group/btn on the Buy Now button. Tailwind's named group feature uses the /name suffix to keep them separate:

// Card-level hover: zooms the product image

  

// Button-level hover: triggers the ripple animation

Without named groups, hovering the button would also trigger the card's hover styles. The /card and /btn suffixes prevent this.

2. CSS ripple animation on the Buy Now button

The ripple effect uses a pure CSS scale animation. A white circle (w-8 h-8 rounded-full) starts at scale-0 and transitions to scale-[20] when the button is hovered. The overflow-hidden on the Button clips it to the button's boundary. The z-10 on the label keeps the text visible above the expanding circle.

3. Ordinal suffix logic for the delivery date

The getDeliveryDate() function calculates a date three days from now and attaches the correct ordinal suffix (st, nd, rd, th):

const suffix = ["th", "st", "nd", "rd"][
  day % 10 > 3 ? 0 : (day % 100 - day % 10 !== 10 ? day % 10 : 0)
];

The logic handles the edge cases for 11th, 12th, and 13th, which always use "th" regardless of their last digit. This is a common gotcha in ordinal formatting.

4. `suppressHydrationWarning` on the delivery date span

The delivery date is calculated at render time using new Date(). The server calculates it at request time, and the client recalculates it at hydration time.

If there's a timezone difference, React throws a hydration mismatch warning. suppressHydrationWarning silences this warning for that specific node without affecting the rest of the tree.

Live Preview:

Quick Reference Table

Card	Identifier	Use Case
Preview Card	`card-02`	Property listings, hotel cards, product previews
Analytics Card	`card-05`	Dashboard widgets with metric data
Statistics Card	`card-06`	E-commerce stats grids
Product Variant Card	`card-17`	Product pages with size selection and cart

To install any of these, replace the identifier in the CLI command:

npx shadcn@latest add @shadcn-space/

Key Concepts Recap

Here's a summary of the key Tailwind, React, and TypeScript patterns used across the four cards in this tutorial.

Tailwind Group Hover

The group class on a parent element lets any child respond to the parent's hover state using group-hover: classes.

For nested hover scopes, use named groups like group/card and group/btn with group-hover/card: and group-hover/btn:. This prevents hover styles from bleeding across component boundaries.

The `cn()` Utility

cn() from @/lib/utils merges Tailwind class strings, handles conditional class logic, and de-duplicates conflicting Tailwind utilities. Use it instead of template literals whenever you have conditional classes.

`last:` Tailwind Variant

The last: pseudo-class variant targets the last child element in a group. In the Statistics Card, last:border-e-0 remove the trailing border from the final column without any index tracking in JavaScript.

CSS Logical Properties

border-e means "border at the inline end," which is the right side in LTR layouts and the left side in RTL layouts. Using logical properties like border-e, ps-, and pe- instead of border-r, pl-, and pr- makes your components locale-aware by default.

TypeScript Optional Props with Defaults

Assigning a default value directly in the function signature, like ({ mainDashboard = mainDashboardData }: WidgetProps), is a clean pattern for components that need sensible fallback data while still being configurable. It works for demos, Storybook, and production use with real API data.

`"use client"` in Next.js App Router

Any component that uses useState, browser APIs, or client-only packages like @iconify/react needs the "use client" directive at the top of the file. Without it, the Next.js App Router will try to render the component on the server and throw an error.

`suppressHydrationWarning`

When a value rendered on the server (for example, the current date or time) differs from the value rendered on the client due to timezone differences, React throws a hydration mismatch warning. Adding suppressHydrationWarning to the specific element silences the warning without affecting the rest of the component tree.

CSS Ripple Animation Pattern

A CSS ripple effect can be built without JavaScript by using a scale-0 to scale-[N] transition on a rounded-full element placed inside an overflow-hidden container. On hover, the circle expands and gets clipped by the container boundary. The label text sits above it with relative z-10.

Conclusion

In this tutorial, you built four production-ready card components using shadcn/ui and Base UI primitives:

Preview Card: group hover image animation, overflow clipping, and a logical border amenity row
Analytics Card: typed props with default data, conditional badge colors with cn(), and an absolutely-positioned decorative image
Statistics Card: data-driven repeating layout, responsive flex columns, and automatic last-border removal with last:
Ecommerce Product Variant Card: named hover groups, a CSS ripple button, ordinal date formatting, and hydration warning suppression

Each card is installed with one CLI command and lives in your project's source tree. You own the code and can modify anything to fit your design system.

The patterns covered here, from named group hover scopes to typed props with defaults to logical CSS properties, apply well beyond card components. You'll find them useful across most UI components you build with shadcn/ui and Tailwind CSS.

Resources

Shadcn UI: Component library and documentation home
Shadcn Card Component Collection: All card variants available in Radix and Base UI
How to Use the Shadcn CLI: Getting started guide for the CLI and registry setup
Shadcn CLI Reference: Full CLI command reference
Component Getting Started Guide: How to install and use individual components
Shadcn Components: Full component library with all available categories
Shadcn Dashboard UI Blocks: Ready-to-use dashboard layout blocks built from the same system
Official Shadcn/ui Documentation
Shadcn Figma Kit: Figma UI kit that mirrors the Shadcn Space component system
Video Walkthrough: How to Use Shadcn Space with CLI: YouTube tutorial for CLI setup and component installation
@iconify/react on npm: Icon library used in the Statistics Card

How to Build a Dark Mode Toggle Without JavaScript

Jakub T. Jankiewicz — Mon, 06 Jul 2026 13:55:11 +0000

Over the years, I've worked on many Static Site Generated (SSG) websites that work without JavaScript. And during that time, I've created a few solutions. One of them is a dark mode toggle that doesn't require JavaScript.

I created this solution for my own blog, and then I enhanced it for the WikiZEIT project. I also included the improved version in my Eleventy starter "Complite".

In this article, I'll explain how to create a dark mode toggle with just HTML and CSS with help from the new :has() selector. I will also use CSS variables.

Why Should Websites Work Without JavaScript?
HTML Structure
CSS Code
- Styling the Toggle
- CSS Variables and the Website Style
Conclusion

Why Should Websites Work Without JavaScript?

If you're wondering why a website may benefit from using no JavaScript, there are several reasons, like accessibility (a11y), SEO, and AI visibility.

Modern screen readers can handle JavaScript websites, but this isn't the only thing you should care about. People might be using old computers or phones. Others might have poor internet connections and may disable JavaScript to use less bandwidth.

As for SEO, Google is one of the few major crawlers that can reliably render JavaScript-heavy pages, but rendering can still take extra time compared with indexing server-rendered HTML. Many AI crawlers and answer engines don't appear to execute JavaScript the way a browser does. They often work from the raw HTML response.

So if, for example, you have a React app that's purely client-side rendered, a bot that only reads the initial HTML may see little more than

until JavaScript runs.

To be clear, the issue isn't React itself, but client-side rendering. Server-side rendering, static generation, or prerendering can make your content available in the initial HTML so search engines and AI crawlers can read it more reliably.

But the point remains: if you want your website to be reliably more accessible to all people and machines, you should make it work even without JavaScript.

Note that your website doesn't need to be written in pure/only HTML and CSS. As mentioned above, if you use solutions like React, consider also using a framework like Next.js with Static Site Rendering (SSR) or a Static Site Generator (SSG) like Hugo. You can also consider modern SSG solutions like Eleventy that I'm using.

To learn more about Elventy and Hugo, you can read those two articles:

To learn more about Next.js, you can search videos on YouTube (but remember to check if they explain the modern App Router, not the old Page Router).

HTML Structure

Alright, now that you understand why this approach can be useful, let's dive in and build our dark mode toggle. The HTML of the toggle uses HTML radio buttons:

The above code uses moon and sun emojis.

CSS Code

Now let's see the CSS part of the solution. The trick to making this work without JavaScript involves using this CSS :has pseudo-class:

:has(#mode_dark:checked)

The way this works is a bit like a parent selector that was always missing in CSS. If you have some code like this p:has(img), it will match all

tags that have images inside.

In our case, :has will match when there's a radio button or checkbox selected anywhere on the page. This is the :checked part and and #mode_dark is the id of the input for the dark mode that we have in the HTML Structure section.

So to summarize, you can add :has to any element that can be styled when dark mode is selected. Here's an example:

html:has(#mode_dark:checked) p {
  color: white;
  background: black;
}

This CSS will style all

tags when dark mode is enabled.

The above example (plus the HTML) is everything you need to create a CSS-only dark mode switch.

Styling the Toggle

Here's the CSS that styles the toggle so only one emoji (sun or moon) is displayed at a time. This is only to make the toggle look nice.

The code also makes sure that the initially selected value is always the system-preferred mode.

/* style of the toggle */
.theme-toggle {
  display: flex;
  align-items: center;
}

/* hide the input */
.theme-toggle input[type="radio"] {
  appearance: none;
  -webkit-appearance: none;
  margin: 0;
  position: absolute;
  opacity: 0;
  pointer-events: none;
}
.theme-toggle label {
    width: 40px; height: 40px;
    display: grid;
    place-items: center;
    cursor: pointer;
}

/* icon visibility
 *
 * default light with system and radio button overwrite
 */
label[for="mode_light"] { display: none; }
label[for="mode_dark"] { display: grid; }

@media (prefers-color-scheme: dark) {
  label[for="mode_light"] { display: grid; }
  label[for="mode_dark"] { display: none; }
}
:root:has(#mode_dark:checked) label[for="mode_light"] {
   display: grid;
}
:root:has(#mode_dark:checked) label[for="mode_dark"] {
   display: none;
}
:root:has(#mode_light:checked) label[for="mode_light"] {
   display: none;
}
:root:has(#mode_light:checked) label[for="mode_dark"] {
   display: grid;
}

The :root selector above means the root of the HTML tree. It's often used instead of html.

The CSS code @media (prefers-color-scheme: dark) is a media query, a way to add CSS code when special conditions are met. Here the media query is checking whether the user has system settings set to dark mode.

The code hides the inputs, and the labels control the toggle of the radio button. This is a common way to style radio buttons and checkboxes.

💡

The toggle always displays the mode that it's switching into. That's why in dark mode the sun is showing, not the moon.

CSS Variables and the Website Style

The last part is to style the website. Here we have CSS variables with only two colors. But in a real website, you might have all colors and settings for the dark/light mode that's applied to the whole page:

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #252525; /* dark gray */
    --fg: #fff;    /* white */
  }
}
:root:has(#mode_dark:checked) {
  --bg: #252525; /* dark gray */
  --fg: #fff;    /* white */
}
:root:has(#mode_light:checked) {
  --bg: #fff;    /* white */
  --fg: #252525; /* dark gray */
}

It's useful to use CSS variables because you can put styles that change between dark and light mode in one place. And then you can use one variable instead of hardcoding each style all over your CSS file.

So instead of using code like this:

html:has(#mode_dark:checked) p {
  color: #fff;
  background: #252525;
}

You can use variables:

html:has(#mode_dark:checked) p {
    background: var(--bg);
    color: var(--fg);
}

In case of background and foreground colors, you only need this code:

body {
  background: var(--bg);
  color: var(--fg);
}

You can read more about CSS variables with the :root selector in this article:

CSS Variables Definition – What are CSS Vars and How to Use Them?

Conclusion

When creating a website, it's always worth making it work without JavaScript. It's good for accessibility and SEO.

Now with modern CSS, most of the things a website needs can be done without JS. You should incorporate progressive enhancement and add JavaScript on top of the existing HTML/CSS foundation.

To read more about progressive enhancement, check this article: What is Progressive Enhancement, and why it matters.

And here is a CodePen demo of the whole solution.

If you have any questions, you can contact me on Twitter/X. My DMs are open. You can also check out my personal blog.

How to Build a Browser-Based PDF Analyzer Using JavaScript

Bhavin Sheth — Fri, 03 Jul 2026 15:37:58 +0000

PDF files are one of the most widely used document formats for sharing reports, invoices, contracts, books, research papers, manuals, forms, and business documents. Although viewing a PDF is simple, understanding what's inside the document is often much more difficult.

For example, you may need to know how many pages a PDF contains, whether it's password protected, who created it, what metadata it includes, how much text it contains, which fonts are used, or whether the document contains embedded images.

Manually inspecting all of this information can be time-consuming, especially when working with large collections of PDF files.

A PDF Analyzer solves this problem by automatically extracting detailed information from a document. Instead of opening the file in multiple applications, users can upload a PDF once and instantly view metadata, security settings, text statistics, image information, page details, fonts, and much more.

In this tutorial, you'll build a browser-based PDF Analyzer using JavaScript. The application allows users to upload a PDF, preview its pages, configure analysis options, perform different levels of document analysis, inspect the extracted information, and export a complete analysis report in multiple formats.

Everything runs directly inside the browser without requiring a backend server, making document analysis fast, private, and secure.

By the end of this tutorial, you'll have a fully functional PDF Analyzer capable of examining both simple and complex PDF documents.

Why PDF Analysis Is Useful
How PDF Analysis Works
Project Setup
What Library Are We Using?
Creating the Upload Interface
Previewing Uploaded PDF Pages
Configuring Analysis Settings
Analyzing the PDF
Displaying the Analysis Report
Exporting the Analysis Report
Demo: How the PDF Analyzer Works
Important Notes from Real-World Use
Common Mistakes to Avoid
Conclusion

Why PDF Analysis Is Useful

Most people think of a PDF as simply a document that can be viewed or printed, but every PDF contains much more information than what appears on the screen.

Behind every document is a collection of properties such as metadata, security settings, page information, fonts, embedded images, and document statistics. Accessing this information can help users better understand the document before editing, sharing, printing, or archiving it.

Businesses often receive hundreds of PDF files every day from clients, suppliers, government departments, and employees. Before these files are stored or distributed, they frequently need to be inspected to verify their contents. A PDF Analyzer makes this process much faster by automatically extracting important document information.

Legal professionals regularly review contracts and agreements where document properties such as creation dates, authorship, and security restrictions may be important. Instead of manually checking each document, an analyzer provides these details in seconds.

Educational institutions use PDF analysis when reviewing assignments, research papers, and digital course materials. Teachers and administrators can quickly inspect page counts, metadata, extracted text, and document properties before storing or distributing files.

Publishing companies analyze PDF files before printing books, manuals, catalogs, and magazines. Reviewing page sizes, fonts, metadata, and embedded resources helps identify formatting problems before production begins.

Government agencies and healthcare organizations also benefit from document analysis when processing applications, medical records, permits, forms, and official reports. Verifying document integrity before long-term storage helps reduce errors and maintain consistent records.

A PDF Analyzer is equally useful for developers. Before building editing tools such as watermarking, page rotation, cropping, metadata editing, or page extraction, developers often need to inspect the document structure to determine how it should be processed.

Because this application performs all analysis directly inside the browser, users can inspect sensitive documents without uploading them to external servers. This provides an additional layer of privacy while delivering instant results.

How PDF Analysis Works

A PDF Analyzer reads the uploaded document and extracts useful information from its internal structure.

Once the user selects a PDF file, the browser loads the document into memory. Instead of modifying the PDF, the application examines its contents and collects various types of information that can later be displayed in a structured report.

The analysis begins by reading the document itself. Basic properties such as the filename, total number of pages, and file size are identified immediately.

Next, the application extracts metadata including the document title, author, subject, keywords, creator, producer, creation date, modification date, and PDF version.

The analyzer can also inspect security-related properties to determine whether the document is password protected or contains restrictions on printing, copying, or editing.

After processing the document structure, the application examines each page individually. It can count words, characters, images, fonts, estimate reading time, calculate speaking time, and even perform sentiment analysis on extracted text when OCR is enabled.

If the uploaded document consists of scanned pages instead of selectable text, OCR can be used to recognize text before analysis begins.

Once all information has been collected, the application generates a complete report that can be viewed inside the browser or exported as a PDF, JSON, CSV, or text file.

Since the entire workflow runs locally, the original document remains on the user's device throughout the process.

Project Setup

We'll build this project using standard web technologies.

Create the following files:

pdf-analyzer/

│── index.html

│── style.css

│── script.js

Next, include the required libraries inside index.html.

These libraries provide everything needed for PDF loading, rendering, OCR processing, and report visualization.

What Library Are We Using?

This project combines several JavaScript libraries because no single library can perform every type of PDF analysis.

The primary library is PDF-lib, which allows the application to load PDF documents and access important document properties such as metadata and page information. It's lightweight, fast, and runs entirely inside modern browsers.

The project also uses PDF.js to render document pages for previews. This enables users to visually inspect uploaded PDFs before running the analysis.

For scanned documents that don't contain selectable text, Tesseract.js provides Optical Character Recognition (OCR). It recognizes text directly inside the browser, making it possible to analyze scanned PDFs without requiring any server-side processing.

To visualize analysis results, we'll use Chart.js for generating simple graphs and statistics such as word counts, sentiment distribution, and other document metrics.

Together, these libraries create a powerful browser-based PDF Analyzer capable of extracting metadata, rendering previews, recognizing scanned text, generating statistics, and exporting detailed analysis reports while keeping every document completely private.

Creating the Upload Interface

Every PDF workflow begins with selecting a document. Before any analysis can take place, users need a simple and reliable way to upload one or more PDF files into the browser.

A good upload interface should clearly indicate that only PDF documents are accepted while supporting both drag-and-drop uploads and the traditional file picker. This makes the tool easy to use regardless of whether users are working on a desktop or a mobile device.

In this project, the upload area acts as the entry point for the entire analysis process. When a user selects a PDF, the browser validates the file type, loads the document into memory, and prepares it for previewing and analysis. Since everything happens locally, the original PDF never leaves the user's device.

Our upload component displays a drag-and-drop area, a browse button, and helpful instructions that guide users through the first step of the workflow.

Here's the HTML for the upload area:



    

        
            ☁
        

        Drag & Drop PDF Here

        Or click to browse file

Next, register the file input and handle PDF selection.

const pdfInput = document.getElementById("pdfInput");

pdfInput.addEventListener("change", async (event) => {

    const file = event.target.files[0];

    if (!file) return;

    if (file.type !== "application/pdf") {

        alert("Please select a valid PDF file.");

        return;

    }

    loadPDF(file);

});

This validation prevents unsupported file types from being processed while ensuring the application only loads valid PDF documents.

After the upload interface is complete, users can immediately select a document and move to the preview stage.

Previewing Uploaded PDF Pages

Once a PDF has been uploaded, it's helpful to display a visual preview before starting the analysis. This allows users to verify that they selected the correct document and quickly inspect its pages.

Instead of showing only the file name, our application renders thumbnail previews of every page in the PDF. Users can scroll through the thumbnails to inspect the document and confirm that all pages loaded successfully.

Displaying previews also improves the user experience because it gives immediate visual feedback while the document is being prepared for analysis.

The browser uses PDF.js to render each page as a canvas before converting it into an image that can be displayed inside the page preview grid.

The following code loads the PDF document:

const pdf = await pdfjsLib.getDocument({

    data: await file.arrayBuffer()

}).promise;

Next, render each page:

for (let pageNumber = 1; pageNumber <= pdf.numPages; pageNumber++) {

    const page = await pdf.getPage(pageNumber);

    const viewport = page.getViewport({

        scale: 0.35

    });

    const canvas = document.createElement("canvas");

    const context = canvas.getContext("2d");

    canvas.width = viewport.width;

    canvas.height = viewport.height;

    await page.render({

        canvasContext: context,

        viewport

    }).promise;

    previewContainer.appendChild(canvas);

}

Each page is rendered independently, making it possible to preview documents containing dozens or even hundreds of pages.

The preview shown in this project displays all page thumbnails together, making it easy to verify page order before continuing.

Configuring Analysis Settings

Before analyzing the document, users can customize how the application should examine the PDF.

Different documents require different levels of analysis. Some users may only need basic information such as the page count and metadata, while others may want detailed statistics about extracted text, embedded images, fonts, security permissions, and OCR results.

To support these different scenarios, the PDF Analyzer provides several configurable options before processing begins.

The first option allows users to choose which pages should be analyzed. They can analyze every page in the document or specify a custom page range when only certain pages are relevant.

For scanned PDFs, OCR can be enabled to recognize text that's stored as images rather than selectable characters. Users can also select the OCR language before processing starts.

Finally, the application offers multiple analysis levels. Basic mode extracts essential document information such as metadata and security properties. Standard mode additionally collects text and image statistics. Advanced mode performs the most detailed inspection available, including fonts, page-level statistics, OCR processing, and sentiment analysis.

The analysis settings panel gives users complete control over how the document should be processed while keeping the interface simple and easy to understand.

Here's the HTML used for the settings panel:

Users can also enable OCR when analyzing scanned PDF documents:

const enableOCR = document.getElementById("enableOCR").checked;

const language = document.getElementById("ocrLanguage").value;

if (enableOCR) {

    console.log("OCR Enabled");

    console.log(language);

}

Finally, capture the selected analysis level:

const level = document.getElementById("analysisLevel").value;

switch (level) {

    case "basic":

        runBasicAnalysis();

        break;

    case "standard":

        runStandardAnalysis();

        break;

    case "advanced":

        runAdvancedAnalysis();

        break;

}

These settings allow the application to adapt to many different types of PDF documents, from simple text files to complex scanned reports containing images, metadata, and security restrictions.

Analyzing the PDF

Once the PDF has been uploaded, previewed, and the analysis options have been configured, the application is ready to examine the document.

Unlike editing tools that modify pages, a PDF Analyzer inspects the document and extracts useful information without changing the original file. The analyzer reads the PDF structure, examines each page, and collects information that can later be displayed in a detailed report.

The analysis begins by loading the uploaded document into memory. From there, the application extracts basic information such as the filename, file size, total number of pages, and document validity. It then reads metadata including the title, author, subject, creator, producer, creation date, modification date, and PDF version.

Depending on the selected analysis level, the application can also inspect security permissions, count words and characters, estimate reading time, identify embedded images, list fonts used throughout the document, and perform OCR on scanned PDFs. When OCR is enabled, the analyzer converts scanned images into searchable text before calculating document statistics.

Because the application processes everything inside the browser, users receive instant results while maintaining complete privacy.

The first step is loading the uploaded PDF:

async function analyzePDF(file){

    const bytes = await file.arrayBuffer();

    const pdf = await PDFLib.PDFDocument.load(bytes);

    return pdf;

}

Next, extract the document metadata:

const metadata = {

    title: pdf.getTitle(),

    author: pdf.getAuthor(),

    subject: pdf.getSubject(),

    creator: pdf.getCreator(),

    producer: pdf.getProducer(),

    keywords: pdf.getKeywords(),

    creationDate: pdf.getCreationDate(),

    modificationDate: pdf.getModificationDate()

};

Basic document information is also collected:

const fileInfo = {

    fileName: file.name,

    fileSize: file.size,

    totalPages: pdf.getPageCount(),

    valid: true

};

If the user selects Advanced Analysis, additional routines extract page statistics, fonts, images, OCR results, and text analysis:

if(selectedLevel === "advanced"){

    analyzeFonts();

    analyzeImages();

    analyzeText();

    performOCR();

}

Once every analysis step has finished, the application combines the collected information into a single report object that will be displayed in the next stage.

Displaying the Analysis Report

After processing is complete, the application presents the collected information inside a structured report.

Instead of showing raw JSON or technical output, the report organizes related information into separate cards. This layout makes it much easier for users to understand large amounts of document information.

The first section displays basic document information, including the filename, file size, total number of pages, and validation status.

The metadata section contains properties such as the document title, author, subject, keywords, creator, producer, PDF version, creation date, and modification date.

Security information indicates whether the document is password protected and whether printing, copying, or modification restrictions are present.

When text analysis is enabled, the report includes the total word count, character count, average words per page, estimated reading time, and estimated speaking time. If OCR has been performed, the extracted text is also analyzed to calculate sentiment statistics.

Additional cards display image information, embedded fonts, and page-by-page extracted text for users who need a deeper inspection of the document.

The following example creates a simple report section:

function renderBasicInfo(info){

    document.getElementById("fileName").textContent = info.fileName;

    document.getElementById("pageCount").textContent = info.totalPages;

    document.getElementById("fileSize").textContent = info.fileSize;

}

Rendering the metadata is straightforward:

function renderMetadata(metadata){

    title.innerText = metadata.title;

    author.innerText = metadata.author;

    creator.innerText = metadata.creator;

    producer.innerText = metadata.producer;

}

Page-wise extracted content can also be displayed:

pages.forEach((page,index)=>{

    createPageCard(

        index + 1,

        page.text

    );

});

Organizing the results into individual sections allows users to quickly locate the information they need without scrolling through large blocks of text.

Exporting the Analysis Report

After reviewing the analysis results, users often need to save the report for future reference or share it with colleagues.

To support different workflows, the PDF Analyzer allows the report to be exported in several formats. Depending on the user's needs, the report can be downloaded as a PDF document, JSON file, CSV spreadsheet, or plain text file.

PDF reports are useful for documentation and sharing with clients or team members. JSON exports are ideal for developers who want to process the analysis programmatically. CSV files can be opened in spreadsheet applications for further analysis, while text files provide a simple human-readable version of the report.

Providing multiple export formats makes the analyzer suitable for business users, developers, researchers, and system administrators alike.

The following example creates a JSON export:

const report = JSON.stringify(

    analysisResult,

    null,

    2

);

Create a downloadable file:

const blob = new Blob(

    [report],

    {

        type:"application/json"

    }

);

Generate the download link:

const url = URL.createObjectURL(blob);

const link = document.createElement("a");

link.href = url;

link.download = "analysis-report.json";

link.click();

The export menu allows users to choose the most appropriate output format before downloading the completed report.

Demo: How the PDF Analyzer Works

Step 1: Upload Your PDF File

The process begins by uploading a PDF document using either the drag-and-drop area or the file selection button.

Once a file is selected, the browser validates that it's a PDF before loading it into memory. Because the application runs entirely inside the browser, the uploaded document never leaves the user's device, making the tool suitable for confidential business reports, contracts, invoices, research papers, legal documents, and other sensitive files.

After the PDF is loaded successfully, the application prepares it for page preview generation and document analysis.

Step 2: Preview Uploaded PDF Pages

After the document has been loaded, the application generates page previews for the uploaded PDF.

Displaying page thumbnails allows users to confirm that the correct file has been selected before analysis begins. Users can quickly browse through the document, inspect page order, and verify that every page has loaded successfully.

This visual preview also helps identify scanned pages, blank pages, or unexpected formatting issues before processing.

Step 3: Configure Analysis Settings

Next, users configure how the PDF should be analyzed.

The tool allows users to choose whether every page or only a specific page range should be processed. For scanned PDFs, OCR can be enabled to recognize text stored as images, and users can select the appropriate recognition language.

The application also offers multiple analysis levels. Basic mode extracts essential document properties, Standard mode adds text and image statistics, and Advanced mode performs a more detailed inspection that includes fonts, OCR, page-level information, sentiment analysis, and additional document insights.

These settings allow users to customize the analysis based on the type of PDF they are working with.

Step 4: Analyze the PDF

Once the settings have been reviewed, users simply click the Analyze PDF button.

The browser reads the uploaded document and extracts the selected information. Depending on the chosen analysis level, the application examines metadata, security settings, page information, extracted text, fonts, embedded images, and OCR results.

Although large documents may require a few additional seconds, the entire analysis is completed locally without uploading the PDF to a remote server.

Step 5: Review the Analysis Report

After processing is complete, the application displays a comprehensive analysis report.

The report is divided into multiple sections that make it easy to inspect different aspects of the document. Users can review basic document information, metadata, security settings, extracted text statistics, page information, fonts, embedded images, OCR results, estimated reading time, speaking time, and sentiment analysis.

Each section is organized into individual cards so that important information can be located quickly.

Step 6: Review Page-Level Analysis

For users who need more detailed information, the application also displays page-by-page analysis.

Each page can include extracted text, OCR output, word count, image statistics, page dimensions, and additional information collected during processing.

This level of detail is especially useful when analyzing large reports, scanned books, research papers, contracts, technical documentation, and multi-page business documents.

Step 7: Export the Analysis Report

After reviewing the analysis, users can export the report for future reference.

The tool supports multiple export formats, including PDF, JSON, CSV, and plain text. This allows developers, researchers, businesses, and system administrators to choose the format that best fits their workflow.

Exported reports can be archived, shared with team members, imported into other systems, or used for additional processing.

Once the desired format is selected, the browser generates the report and downloads it instantly.

Important Notes from Real-World Use

A PDF Analyzer can process everything from a single-page document to large reports containing hundreds of pages. While modern browsers handle most documents efficiently, larger files containing high-resolution images or scanned pages may require additional processing time, especially when OCR is enabled.

Before starting the analysis, it's good practice to validate the uploaded file.

if (file.type !== "application/pdf") {

    alert("Please upload a valid PDF document.");

    return;

}

If OCR is enabled, remember that recognizing text from scanned pages takes longer than extracting text from a standard searchable PDF. Users should only enable OCR when it's actually needed.

if(enableOCR){

    console.log("Running OCR Analysis...");

}

When analyzing very large documents, processing pages individually helps reduce memory usage and keeps the browser responsive.

for(let page = 1; page <= pdf.numPages; page++){

    analyzePage(page);

}

Before exporting the report, review the extracted information to ensure metadata, text statistics, page information, and OCR results are accurate.

Common Mistakes to Avoid

One common mistake is running OCR on documents that already contain selectable text.

OCR is designed for scanned PDFs where text exists only as images. Running OCR on searchable PDFs increases processing time without improving the analysis.

if(pdfContainsText){

    enableOCR = false;

}

Another mistake is selecting the wrong analysis level.

For example, users who only need metadata and document properties can choose Basic Analysis instead of Advanced Analysis, which performs additional processing such as OCR, font inspection, sentiment analysis, and image detection.

const analysisLevel = "basic";

console.log(analysisLevel);

Some users also forget to verify the page selection before starting the analysis.

When working with large reports, analyzing only the required pages can significantly reduce processing time.

const pageRange = "1-20";

console.log(pageRange);

Finally, always review the generated report before exporting it.

A quick inspection helps verify that metadata, page statistics, OCR output, document properties, and extracted text are accurate before downloading the final report.

Taking a few extra moments to validate the results can save considerable time when working with large document collections.

Conclusion

In this tutorial, you built a browser-based PDF Analyzer using JavaScript.

You learned how to upload PDF files, preview document pages, configure analysis options, inspect metadata, analyze document structure, extract text, perform OCR, generate detailed reports, and export the analysis in multiple formats directly from the browser.

More importantly, you saw how modern browsers can inspect complex PDF documents without requiring a backend server or uploading files to third-party services.

This approach keeps document analysis fast, private, and secure while giving users valuable insights into the contents and structure of their PDF files.

You can try the complete implementation here:

PDF Analyzer: https://allinonetools.net/pdf-analyzer/

Once you understand this workflow, you can extend the project further by adding AI-powered document summarization, keyword extraction, duplicate document detection, document comparison, accessibility analysis, compliance checking, digital signature validation, or advanced reporting dashboards.

How to Build an AJAX Cart Drawer in Shopify (the 2026 Way)

baslefeber — Fri, 03 Jul 2026 15:30:18 +0000

Add a product to a Shopify store the default way and the whole page reloads. The shopper is looking at your product, they click Add to cart, and the browser throws the page away and rebuilds it.

On a slow connection, that's two or three seconds of blank screen. Sometimes they even land on /cart, a full page away from the thing they were about to buy, and the momentum is gone.

A cart drawer fixes that. It's the slide-out panel that appears when someone adds an item: the cart updates, a Checkout button sits right there, and the shopper never leaves the page they were on.

Nearly every high-converting Shopify store has one, and you don't need an app to build it. You need two Ajax endpoints and less than a hundred lines of JavaScript.

The catch is that most tutorials, and most AI coding tools, build it the fragile way. They keep a running count in a JavaScript variable and update the DOM by hand. That looks fine in a demo and falls apart the first time two lines merge into one, a discount lands, or a variant sells out between the click and the checkout.

This guide builds it the way a senior developer does, where the server is always the source of truth. Then it shows the 2026 addition that lets your drawer speak the same language as apps and AI shopping agents.

If you want to code along, open a development theme you can edit and build each piece as we go. Everything here runs on a stock Online Store 2.0 theme (Horizon or Dawn) with no app installed.

The finished drawer: add to cart, no page reload, the panel slides in showing the real cart.

What You'll Build
Step 1: The Drawer Markup
Step 2: Add to Cart Without a Reload
Step 3: Render the Drawer from the Server's Truth
Step 4: Quantity Plus and Minus, with Event Delegation
Step 5: Remove a Line, and Clear the Cart
Step 6: Re-Rendering with the Section Rendering API (the Version You'd Ship)
The 2026 Upgrade: Standard Storefront Events and Actions
Why This Matters
The Complete Files
Wrap Up

What You'll Build

By the end, you'll have a drawer that:

adds to cart over Ajax with no page reload
re-reads the cart after every change and treats that response as the truth
renders its own contents and slides open
handles quantity plus/minus with a single delegated listener
removes a line and clears the cart
and, as the final upgrade, exposes itself through Shopify's new standard storefront actions so apps and AI agents can drive it

Prerequisites

A Shopify theme you can edit (examples assume Online Store 2.0, such as Horizon or Dawn)
Comfort with fetch and promises
Basic Liquid
No app, no framework, no build step

Step 1: The Drawer Markup

You'll build the drawer as a section so it renders on every page, and then render the current cart server-side with Liquid before any JavaScript runs.

This matters: if a shopper arrives with items already in their cart, the drawer is correct on first paint, and your JavaScript only has to update it after changes. That's progressive enhancement, and it is the first thing a homemade build skips.

The data-* attributes below are the contract between the markup and the script. Everything the JavaScript touches, it finds through one of these attributes, never through a class name or a tag position.

{%- comment -%} sections/cart-drawer.liquid {%- endcomment -%}



  
    Your cart
    
  

  
     0 %}style="display:none"{% endif %}>
      Your cart is empty.
    
    
      {%- for item in cart.items -%}
        
          {{ item.image | image_url: width: 96 | image_tag: class: 'drawer__item-img', loading: 'lazy', alt: item.product.title }}
          {{ item.product.title }}
          {{ item.final_line_price | money }}
        
      {%- endfor -%}
    
  

  
    
      Subtotal
      {{ cart.total_price | money }}
    
    Shipping & taxes calculated at checkout.
    Checkout

Two details worth pausing on here: the line item uses item.final_line_price, not item.line_price. Both exist on the cart, but final_line_price reflects line-level discounts, so it's the number the shopper will actually be charged. And each

carries data-line-key and data-quantity, which the quantity and remove controls will read later.

The add button lives on your product card or product page and carries the variant id straight from Liquid, so the right variant is added every time:

{%- comment -%} in the product card / PDP {%- endcomment -%}

Step 2: Add to Cart Without a Reload

Here is the whole pattern in one sentence: mutate the cart, then re-read it, then render and open. Written out, that is POST /cart/add.js to add the variant, GET /cart.js to read the entire cart back, and then paint the drawer from what came back.

// assets/cart-drawer.js
document.querySelectorAll("[data-add]").forEach(function (btn) {
  btn.addEventListener("click", function () {
    var id = Number(btn.getAttribute("data-variant-id"));
    fetch("/cart/add.js", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ id: id, quantity: 1 }),
    })
      .then(function (r) { return r.json(); })
      .then(function () { return refresh(); })  // re-read /cart.js
      .then(openDrawer);                         // then slide it in
  });
});

Why re-read the cart when /cart/add.js already returned something? Because the response to add.js describes the line you just added, not the whole cart, and the whole cart is what the drawer shows.

More importantly, Shopify is the one that decides the final cart. It might merge your new line into an existing one, apply an automatic discount, or reject a sold-out variant. The only way to be sure the drawer matches reality is to ask for reality. That's what refresh() does, and it's the single function in this whole file that's allowed to touch the cart UI:

function refresh() {
  return fetch("/cart.js").then(function (r) { return r.json(); }).then(render);
}

Both endpoints here (/cart/add.js and /cart.js) are part of Shopify's Ajax API, which is available on every storefront with no setup.

Mutate, then re-read, then render. The same loop runs for add, for quantity changes, and for remove.

Step 3: Render the Drawer from the Server's Truth

render(cart) takes a /cart.js response and paints the drawer from it. Notice what it doesn't do: it never adds up a total or increments a counter. It reads item_count and total_price straight off the object Shopify handed back.

function money(cents) {
  return "$" + (cents / 100).toFixed(2);
}

function render(cart) {
  document.querySelector("[data-cart-count]").textContent = cart.item_count;
  document.querySelector("[data-cart-subtotal]").textContent = money(cart.total_price);

  var itemsEl = document.querySelector("[data-drawer-items]");
  var emptyEl = document.querySelector("[data-drawer-empty]");
  itemsEl.innerHTML = "";
  if (!cart.items.length) { emptyEl.style.display = "block"; return; }
  emptyEl.style.display = "none";

  cart.items.forEach(function (line) {
    var li = document.createElement("li");
    li.className = "drawer__item";
    li.setAttribute("data-line", "");
    li.setAttribute("data-line-key", line.key);
    li.setAttribute("data-quantity", line.quantity);
    li.innerHTML =
      '' +
      '' + line.title + "" +
      '' + money(line.final_line_price) + "";
    itemsEl.appendChild(li);
  });
}

The one thing that trips people up is money. The Ajax API returns prices in cents. A line that costs $18.99 comes back as 1899. Forget to divide by 100 and you ship a $1,899 coffee. The money() helper does that conversion in one place.

One production note: this reads final_line_price, which reflects line-level discounts, so it's the number the shopper is actually charged (line_price is the pre-discount amount). On a multi-currency store, swap the hand-rolled money() for Shopify's own money formatting so the symbol and decimals follow the active market.

The drawer rendered entirely from a /cart.js response. The count, the line, and the subtotal all came from the server.

Step 4: Quantity Plus and Minus, with Event Delegation

Every drawer lets the shopper nudge quantities. The obvious way to wire the plus and minus buttons is to loop over them and attach a click handler to each. Do that and the controls go dead after the first change.

Here's why: every time the cart changes you re-render the list. This replaces those

elements, and the handlers you attached went with the old elements. The new buttons have no listeners.

The fix is event delegation. Attach one listener to the parent that never gets replaced (the

var itemsEl = document.querySelector("[data-drawer-items]");

itemsEl.addEventListener("click", function (e) {
  var inc = e.target.closest("[data-qty-inc]");
  var dec = e.target.closest("[data-qty-dec]");
  if (!inc && !dec) return;

  var line = e.target.closest("[data-line]");
  var key = line.getAttribute("data-line-key");
  var qty = Number(line.getAttribute("data-quantity"));
  var nextQty = inc ? qty + 1 : qty - 1;

  fetch("/cart/change.js", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ id: key, quantity: nextQty }),
  })
    .then(function (r) { return r.json(); })
    .then(render);
});

For this version, render() emits the stepper controls inside each line:

li.innerHTML =
  '' +
  '' + line.title + "" +
  '' +
    '' +
    '' + line.quantity + "" +
    '' +
  "" +
  '' + money(line.final_line_price) + "";

One detail that's easy to get wrong: the change request sends id: key, the line key, not the variant id. A cart can hold the same variant on two separate lines when they carry different line-item properties (an engraving, a gift note). The key is what uniquely identifies a single line, so that's what /cart/change.js wants.

One delegated listener drives every line's stepper, now and after every re-render.

Step 5: Remove a Line, and Clear the Cart

New developers might go looking for /cart/remove.js, but it doesn't exist. In Shopify's cart API, removing a line is changing its quantity to zero on the same /cart/change.js route you just used for the stepper. Clearing the whole cart has its own endpoint, /cart/clear.js, which takes no body.

// Remove: one delegated listener, quantity 0 deletes the line.
itemsEl.addEventListener("click", function (e) {
  var remove = e.target.closest("[data-remove]");
  if (!remove) return;
  var key = e.target.closest("[data-line]").getAttribute("data-line-key");
  fetch("/cart/change.js", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ id: key, quantity: 0 }),
  })
    .then(function (r) { return r.json(); })
    .then(render);
});

// Clear: empty the whole cart, no body.
document.querySelector("[data-cart-clear]").addEventListener("click", function () {
  fetch("/cart/clear.js", { method: "POST" })
    .then(function (r) { return r.json(); })
    .then(render);
});

Both re-render from the server response, same as everything else. That's the discipline that keeps a removed item from lingering in the count: you don't splice the

out of the DOM and hope. You tell the server, then draw what the server says.

Step 6: Re-Rendering with the Section Rendering API (the Version You'd Ship)

Everything so far rebuilds the drawer's HTML in JavaScript. It works, but look at what it costs: your drawer markup now lives in two places, once in the Liquid from Step 1 and once in the template strings inside render(). Change the design and you have to change both, in sync, forever.

Shopify's answer is bundled section rendering. You ask the cart endpoint to return the re-rendered section HTML in the same request that changes the cart. The markup lives only in Liquid, and the server hands you the finished HTML to drop in.

You opt in by adding a sections parameter to the cart request:

fetch("/cart/add.js", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    id: variantId,
    quantity: 1,
    sections: "cart-drawer",              // section id(s), comma-separated
    sections_url: window.location.pathname // optional render context
  }),
})
  .then(function (r) { return r.json(); })
  .then(function (cart) {
    // Shopify returns rendered HTML under `sections`, keyed by id.
    var html = cart.sections["cart-drawer"];
    if (html) {
      document.querySelector("[data-drawer]").innerHTML =
        new DOMParser().parseFromString(html, "text/html")
          .querySelector("[data-drawer]").innerHTML;
    }
    openDrawer();
  });

What's worth knowing about it, all from the Ajax Cart API reference and the Section Rendering API docs:

Bundled section rendering is available on /cart/add, /cart/change, /cart/clear, and /cart/update.
sections is a comma-separated list (or array) of section IDs, up to five.
sections_url must begin with /. If you omit it, sections render in the context of the current page (based on the Referer header).
The rendered HTML comes back under the sections key of the JSON response, keyed by section ID.
A section that fails to render, including one that doesn't exist, comes back as null with an HTTP 200. Always guard for null.
The section ID is section.id in Liquid, or the id="shopify-section-[id]" on the wrapper. For a section rendered by filename (for example {% section 'cart-drawer' %} in theme.liquid), the ID is just cart-drawer. Inside a JSON template it gets a dynamic ID like template--123__cart-drawer, so check the wrapper before you hardcode the key.

The plain Section Rendering API (a GET with ?sections= or ?section_id= appended to any page URL) is the same idea for non-cart updates like paginated search or infinite scroll. Shopify's own guidance is: for anything driven by a cart change, prefer bundled section rendering over a separate call, because it saves a round trip.

This isn't a toy pattern. Shopify's own Horizon theme drives its cart exactly this way: its cart components send a sections list on their /cart/change.js calls and re-render from response.sections, reading each section's id from a data attribute rather than hardcoding it. That's the production version of the caveat above: never assume the id is a bare cart-drawer. Read it off the rendered wrapper instead.

The 2026 Upgrade: Standard Storefront Events and Actions

Everything above is timeless Shopify. Now the new part.

On June 17, 2026, as part of the Spring '26 Edition, Shopify shipped standard storefront events and actions, and they're generally available.

The idea is that themes now emit a standardized set of DOM events (all namespaced shopify:) and expose a standardized set of actions on Shopify.actions. An app or an AI shopping agent can now interact with any storefront through one contract, instead of reverse-engineering each theme's private JavaScript.

To feel why that matters, think about how an upsell app used to detect an add-to-cart on a theme it had never seen.

It had four bad options: monkey-patch fetch to sniff calls to /cart/add, listen for a theme-specific custom event whose name changed from theme to theme, poll /cart.js on a timer and diff it, or scrape the DOM for a cart-count node by selector. Every one of them breaks when the merchant reskins or switches themes.

This is also the exact code an AI assistant tends to generate when you ask it to "run something after add to cart," because that brittle pattern dominates its training data.

The problem was never that the developer was careless. There was simply no stable interface to target.

Four fragile per-theme tactics collapse into one integration against a contract that survives a reskin.

Crucially, this layer sits on top of the drawer you just built. It doesn't replace the Ajax API. The docs even show the theme-side event wrapping the same /cart/add.js and /cart.js calls, and Shopify shipped a helper whose only job is to convert a /cart.js response into the event's payload shape. So none of your work is wasted. You're about to give it a public door.

The Events: the Theme Tells the World What Happened

Each event uses the shopify: namespace, follows a category:action naming pattern, dispatches from the most specific element (a product card, the cart, a collection container), and bubbles to document. The payloads follow the Storefront GraphQL API shape, with camelCase fields.

Event	Fires when
`shopify:page:view`	Every page load
`shopify:product:view`	A product becomes visible
`shopify:product:select`	Buyer changes variant selection
`shopify:cart:view`	Cart becomes visible
`shopify:cart:lines-update`	Cart lines added, updated, or removed
`shopify:cart:note-update`	Cart note changes
`shopify:cart:discount-update`	Discount codes applied or removed
`shopify:cart:error`	A cart mutation fails
`shopify:collection:view`	Collection page loads
`shopify:collection:update`	Collection filters or sort change
`shopify:search:update`	Search filters or sort change

An app subscribes with the ordinary DOM API. No SDK:

document.addEventListener('shopify:cart:lines-update', (event) => {
  console.log(event.action, event.lines);
  event.promise?.then(({ cart }) => {
    console.log(cart.cost.totalAmount.amount);
  });
});

The cart, note, discount, product-select, collection-update, and search-update events carry a promise field for their async result. That lets a listener show a loading or optimistic state immediately, then read the settled { cart } when the operation resolves.

Emitting an Event From Your Theme

The events library is hosted on the Shopify CDN. You load it through an import map (for module themes like Horizon) or assign it to a global (for Dawn-style themes).

A theme fires an event by constructing the event class and calling dispatchEvent(). Read this carefully and you'll see that it wraps the exact same /cart/add.js and /cart.js calls from Step 2:

import { CartLinesUpdateEvent, CartErrorEvent } from '@theme/standard-events';

const deferred = CartLinesUpdateEvent.createPromise();
element.dispatchEvent(new CartLinesUpdateEvent({
  action: 'add',
  context: 'product',
  lines: [{ merchandiseId: variantId, quantity: 1 }],
  promise: deferred.promise,
}));

try {
  const response = await fetch(window.Shopify.routes.root + 'cart/add.js', { method: 'POST', body, headers });
  if (!response.ok) throw new Error('Add to cart failed');
  const ajaxCart = await fetch(window.Shopify.routes.root + 'cart.js').then(r => r.json());
  deferred.resolve({
    cart: CartLinesUpdateEvent.createCartFromAjaxResponse(ajaxCart),
  });
} catch (e) {
  element.dispatchEvent(new CartErrorEvent({ error: e.message, code: 'SERVICE_UNAVAILABLE' }));
  deferred.reject(e);
}

That static createCartFromAjaxResponse(ajaxCart) is the bridge between the classic Ajax drawer and the new event contract. It converts your /cart.js response into the Storefront-API-shaped payload the events expect, so the drawer you already have plugs straight in.

The Actions: the World Asks the Theme to Do Something

Actions are async functions on Shopify.actions, injected on every Liquid storefront with no script tag of your own:

// Add, update, or remove lines. Also handles note + discountCodes.
const { cart, userErrors, warnings } = await Shopify.actions.updateCart({
  lines: [
    { merchandiseId: "gid://shopify/ProductVariant/123", quantity: 1 }, // add
    { id: "gid://shopify/CartLine/456", quantity: 5 },                  // update
    { id: "gid://shopify/CartLine/789", quantity: 0 },                  // remove
  ],
});
// Returns: Promise<{ cart, userErrors?, warnings? }>

await Shopify.actions.openCart();                 // Promise
const { cart } = await Shopify.actions.getCart(); // reads current cart

The defaults work on a stock theme with no changes: updateCart writes to the Storefront API and refreshes in place, falling back to a full page reload. openCart opens a or element if one exists, otherwise it redirects to /cart. getCart reads the current cart. And when a configured action succeeds, the runtime auto-emits the matching event, so an app that calls updateCart never has to also dispatch shopify:cart:lines-update.

Overriding an Action to Drive Your Drawer

This is the payoff. Because a theme can override an action's default, you can intercept openCart and updateCart so that any app's call routes through the drawer you already built, instead of triggering a page reload. The app doesn't need to know your markup. It calls the standard action, and your override decides what the UI does.

Register the override inside a DOMContentLoaded listener placed above {{ content_for_header }} in your layout, so it runs before any app code:

document.addEventListener('DOMContentLoaded', () => {
  Shopify.actions.updateCart.configure({
    eventTarget: (meta) => {
      if (meta.type === 'shopify:cart:note-update') return document.querySelector('cart-note');
      if (meta.type === 'shopify:cart:discount-update') return document.querySelector('cart-discount');
      if (meta.type === 'shopify:cart:lines-update' && meta.action === 'add') {
        return document.querySelector('product-form');
      }
      return document.querySelector('cart-items');
    },
    async handler(defaultHandler, payload, options) {
      const result = await defaultHandler();
      customUpdateUI(result); // your render() + openDrawer() from earlier
      return result;
    },
  });
});

openCart has a simpler override:

Shopify.actions.openCart.configure({
  handler() { document.querySelector('cart-drawer')?.open(); },
});

A few rules that will save you time:

eventTarget is required for updateCart. It decides which element the auto-emitted events dispatch from.
getCart is intentionally not configurable. Calling configure() on it is a TypeScript error and a runtime TypeError.
isDefault() tells you whether the theme has overridden an action yet.
updateCart resolves with { cart, userErrors?, warnings?, detail? } and rejects only when it couldn't run at all (a network failure or a malformed payload). A userErrors array means the mutation was rejected (codes like INVALID, MAXIMUM_EXCEEDED). A warnings array means it succeeded with caveats (MERCHANDISE_OUT_OF_STOCK, DISCOUNT_NOT_FOUND). Check both before you trust cart.

The app calls the standard action and knows nothing about your markup. Your override decides the UI.

Verifying it

Run shopify theme dev and the CLI loads a development build of the events runtime that validates payloads and logs a warning when a field is malformed or missing.

Those checks are stripped in production. Add the --standard-events-inspector flag and it injects a floating debug panel into your local pages with two tabs: Events, which shows every emitted standard event live with its full payload, and Actions, which lets you dispatch actions by hand and inspect the result. When you're wiring up payloads, trust the inspector over any tutorial, including this one.

Why This Matters

Two ideas in this build outlast the specific code, and they're the difference between a drawer that works and one you can maintain.

Event Delegation

One listener on a parent that never gets replaced, reading e.target.closest(...), handles every child element: the ones on the page now and the ones you have not rendered yet. Bind a handler per button instead and it dies the instant the list re-renders, which in a cart drawer is constantly.

Delegation is also, not by coincidence, the pattern AI tools most reliably get wrong, because per-element binding is what shows up most in their training data. Knowing to reach for delegation is exactly the kind of judgment that doesn't come from the syntax.

The Section Rendering API

Instead of keeping your drawer's markup in two places and praying they stay in sync, you let the server render the section and hand you the HTML. Your markup lives in one file, and it stays correct when a merchant edits the section in the theme editor.

The trade is a slightly larger response and a parse step, in exchange for never maintaining the same markup twice.

And under all of it, one rule: after every mutation, re-read the cart (or the rendered section) and paint from the server's response. The local counter is the bug. Everything else in this article is a variation on trusting the server.

The Complete Files

For anyone who scrolled straight here, this is the whole thing: the section markup, the JavaScript, and the CSS. The JavaScript combines add, quantity, remove, and clear, all re-rendering from the server response.

sections/cart-drawer.liquid:




  
    Your cart
    
  

  
     0 %}style="display:none"{% endif %}>
      Your cart is empty.
    
    
      {%- for item in cart.items -%}
        
          {{ item.image | image_url: width: 96 | image_tag: class: 'drawer__item-img', loading: 'lazy', alt: item.product.title }}
          {{ item.product.title }}
          
            
            {{ item.quantity }}
            
          
          {{ item.final_line_price | money }}
          
        
      {%- endfor -%}
    
  

  
    
      Subtotal
      {{ cart.total_price | money }}
    
    
    Checkout
  



{% schema %}
{ "name": "Cart drawer" }
{% endschema %}

assets/cart-drawer.js:

(function () {
  var countEl = document.querySelector("[data-cart-count]");
  var itemsEl = document.querySelector("[data-drawer-items]");
  var emptyEl = document.querySelector("[data-drawer-empty]");
  var subtotalEl = document.querySelector("[data-cart-subtotal]");
  var drawer = document.querySelector("[data-drawer]");
  var scrim = document.querySelector("[data-drawer-scrim]");
  var clearBtn = document.querySelector("[data-cart-clear]");

  // --- Add to cart: mutate, re-read, render, open ---
  document.querySelectorAll("[data-add]").forEach(function (btn) {
    btn.addEventListener("click", function () {
      var id = Number(btn.getAttribute("data-variant-id"));
      fetch("/cart/add.js", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ id: id, quantity: 1 }),
      })
        .then(function (r) { return r.json(); })
        .then(function () { return refresh(); })
        .then(openDrawer);
    });
  });

  // --- Quantity +/- : one delegated listener on the stable list ---
  itemsEl.addEventListener("click", function (e) {
    var inc = e.target.closest("[data-qty-inc]");
    var dec = e.target.closest("[data-qty-dec]");
    if (!inc && !dec) return;
    var line = e.target.closest("[data-line]");
    var key = line.getAttribute("data-line-key");
    var qty = Number(line.getAttribute("data-quantity"));
    var nextQty = inc ? qty + 1 : qty - 1;
    fetch("/cart/change.js", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ id: key, quantity: nextQty }),
    }).then(function (r) { return r.json(); }).then(render);
  });

  // --- Remove a line: quantity 0 (there is no /cart/remove.js) ---
  itemsEl.addEventListener("click", function (e) {
    var remove = e.target.closest("[data-remove]");
    if (!remove) return;
    var key = e.target.closest("[data-line]").getAttribute("data-line-key");
    fetch("/cart/change.js", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ id: key, quantity: 0 }),
    }).then(function (r) { return r.json(); }).then(render);
  });

  // --- Clear the whole cart ---
  clearBtn.addEventListener("click", function () {
    fetch("/cart/clear.js", { method: "POST" })
      .then(function (r) { return r.json(); })
      .then(render);
  });

  // --- The one function that paints the drawer from the cart ---
  function money(cents) { return "$" + (cents / 100).toFixed(2); }

  function render(cart) {
    countEl.textContent = cart.item_count;
    subtotalEl.textContent = money(cart.total_price);
    itemsEl.innerHTML = "";
    if (!cart.items.length) { emptyEl.style.display = "block"; return; }
    emptyEl.style.display = "none";
    cart.items.forEach(function (line) {
      var li = document.createElement("li");
      li.className = "drawer__item";
      li.setAttribute("data-line", "");
      li.setAttribute("data-line-key", line.key);
      li.setAttribute("data-quantity", line.quantity);
      li.innerHTML =
        '' +
        '' + line.title + "" +
        '' +
          '' +
          '' + line.quantity + "" +
          '' +
        "" +
        '' + money(line.final_line_price) + "" +
        '';
      itemsEl.appendChild(li);
    });
  }

  function refresh() {
    return fetch("/cart.js").then(function (r) { return r.json(); }).then(render);
  }
  function openDrawer() { drawer.classList.add("is-open"); scrim.classList.add("is-open"); }
  function closeDrawer() { drawer.classList.remove("is-open"); scrim.classList.remove("is-open"); }

  document.querySelector("[data-cart-toggle]").addEventListener("click", function () { refresh().then(openDrawer); });
  document.querySelector("[data-drawer-close]").addEventListener("click", closeDrawer);
  scrim.addEventListener("click", closeDrawer);

  refresh(); // paint on load
})();

assets/cart-drawer.css:

.drawer {
  position: fixed;
  inset: 0 0 0 auto;
  width: min(420px, 100%);
  background: #fff;
  transform: translateX(100%);
  transition: transform 0.3s ease;
  display: flex;
  flex-direction: column;
}
.drawer.is-open { transform: translateX(0); }
.drawer__scrim {
  position: fixed; inset: 0;
  background: rgba(30, 18, 6, 0.45);
  opacity: 0; pointer-events: none;
  transition: opacity 0.3s ease;
}
.drawer__scrim.is-open { opacity: 1; pointer-events: auto; }

Wrap Up

You now have a cart drawer that adds, updates, removes, and clears without a reload, that never lets its UI drift from the real cart, and that, with an action override, presents a clean public interface to the entire app ecosystem, humans and AI agents alike.

The Ajax foundation is the same it has been for years. The 2026 layer sits on top of it, so the drawer you built today is ready for whatever calls it tomorrow.

If you want to build this exact drawer interactively, writing the JavaScript and watching the real storefront react, you can do it for free at learnshopify.dev.

How to Build a Browser-Based PDF Margin Tool Using JavaScript

Bhavin Sheth — Wed, 01 Jul 2026 16:28:38 +0000

Adding margins to a PDF is a common task when preparing documents for printing, binding, archiving, or sharing professionally. While many PDF editors include this feature, they often require installing desktop software or uploading files to an online service.

In this tutorial, you'll learn how to build a browser-based PDF Add Margins Tool using JavaScript. The application allows users to upload a PDF, preview its pages, configure custom margin values, choose measurement units, apply preset margin sizes, select specific pages, and generate an updated PDF directly inside the browser.

Everything runs locally on the user's device using JavaScript, which means documents remain private and no backend server is required. This approach provides fast processing while giving users complete control over how margins are applied.

By the end of this guide, you'll understand how to work with PDF pages, create new page dimensions, reposition existing content, and export a new PDF with the desired margins.

Why PDF Margins Are Useful
How PDF Margin Editing Works
Project Setup
What Library Are We Using?
Creating the Upload Interface
Previewing Uploaded PDF Pages
Configuring Margin Settings
Applying the Margins
Generating the Updated PDF
Demo: How the Add Margins Tool Works
Important Notes from Real-World Use
Common Mistakes to Avoid
Conclusion

Why PDF Margins Are Useful

PDF documents are designed to preserve their appearance across different devices and printers, but that doesn't always mean they're ready for every use case. Many PDFs are created with very little white space around the content, making them difficult to print, bind, annotate, or archive.

Adding margins creates extra space around the page without changing the document's content. This additional white space improves readability, prevents content from being clipped during printing, and provides room for notes, signatures, stamps, or hole punching.

One of the most common uses for PDF margins is printing. Most home and office printers can't print all the way to the edge of the paper, so documents with little or no margin may lose important text or images. Adding margins ensures the entire page fits safely within the printer's printable area.

Margins are also essential when preparing books, manuals, reports, and training materials for binding. Without enough inner spacing, text can disappear into the binding, making the document difficult to read. Publishers often use larger inner margins or mirror margins to create professional-looking printed books.

Businesses regularly add margins before printing invoices, quotations, purchase orders, financial reports, contracts, and presentations. The extra space makes documents easier to file and leaves room for handwritten notes, approval stamps, signatures, or comments.

Students, teachers, and researchers also benefit from margin editing. Universities and educational institutions often require assignments, dissertations, and research papers to follow specific formatting guidelines, including minimum page margins. Instead of recreating the document, users can simply add the required spacing before submission.

Government offices, legal firms, and healthcare organizations frequently work with PDFs that must meet strict printing or filing standards. Adding consistent margins helps ensure forms, applications, agreements, medical records, and official documents are easier to print, review, and archive.

Another practical example comes from e-commerce businesses. Sellers who process hundreds of orders from platforms such as Amazon, Flipkart, or Meesho often print invoices, packing slips, shipping labels, and courier documents in bulk. If the content is positioned too close to the paper edges, some printers may crop important information. Adding consistent margins before printing helps prevent this issue and ensures every document prints correctly.

Because this tool works entirely inside the browser, users can add margins to sensitive PDF documents without uploading them to external servers. This keeps document processing fast, private, and secure while producing professional-looking PDFs that are ready for printing, sharing, binding, or long-term storage.

How PDF Margin Editing Works

Unlike editing text inside a PDF, adding margins doesn't modify the original content. Instead, the application creates a larger page and places the existing page content inside it with the specified spacing around each edge.

When a user uploads a document, the browser first reads every page in the PDF. The application calculates the current page dimensions and determines how much additional space should be added to the top, bottom, left, and right sides.

Depending on the selected settings, the tool can either expand the overall page size while preserving the original content dimensions or keep the existing page size and reposition the content within the available area.

Users can also choose whether the margin changes should be applied to every page or only selected page ranges. Mirror margins are available for printed books where the inner margin alternates between left and right pages to leave room for binding.

After processing every selected page, the browser generates a brand-new PDF containing the updated page dimensions and revised content positioning. Because everything happens locally, no files leave the user's computer during the process.

Project Setup

Before writing any JavaScript, create a simple project structure for the application.

Create a new project folder and add the following files:

pdf-add-margins/
│
├── index.html
├── style.css
├── script.js
└── assets/

The HTML file contains the upload area, preview section, margin settings, and download interface.

The CSS file styles the application and creates the responsive layout used throughout the project.

The JavaScript file handles file uploads, PDF processing, page rendering, margin calculations, and generation of the updated document.

Because everything runs inside the browser, there's no need to configure a backend server or install server-side frameworks.

What Library Are We Using?

This project uses PDF-lib, one of the most popular JavaScript libraries for creating and editing PDF files directly in the browser.

PDF-lib allows developers to load existing PDF documents, create new pages, copy pages between documents, edit document metadata, rotate pages, resize pages, crop pages, add page numbers, insert images, draw text, and export completely new PDF files without relying on external software.

Install PDF-lib using npm:

npm install pdf-lib

Or include it directly from a CDN inside your HTML page:

Once the library is loaded, you can import the required objects:

const {
  PDFDocument
} = PDFLib;

Throughout this tutorial, PDF-lib will be responsible for loading uploaded documents, creating new page dimensions, repositioning page content according to the selected margins, and exporting the finished PDF.

Creating the Upload Interface

The first feature users interact with is the upload interface. A simple and intuitive upload area makes it easy to select a PDF file using either drag-and-drop or the traditional file picker.

In this project, the upload section accepts only PDF documents. Once a valid file is selected, the browser immediately begins loading the document and prepares it for previewing and margin editing.

The upload component also acts as the starting point for the entire workflow. Every action that follows (page preview, margin configuration, page selection, and PDF generation) depends on the uploaded file.

Because the application runs entirely inside the browser, the uploaded PDF never leaves the user's computer. This improves privacy while reducing processing time.

Here's a simple upload field:

Connect the upload button with JavaScript:

const input = document.getElementById("pdfFile");
const button = document.getElementById("selectPDF");

button.addEventListener("click", () => {
    input.click();
});

input.addEventListener("change", async (event) => {

    const file = event.target.files[0];

    if (!file) return;

    const bytes = await file.arrayBuffer();

    console.log("PDF Loaded", bytes);

});

The uploaded PDF is now available for rendering page previews and applying margin settings.

Upload Interface Demo

Previewing Uploaded PDF Pages

Once the PDF has been uploaded successfully, the next step is displaying its pages.

Showing page previews gives users confidence that the correct document has been selected before any changes are made. It also allows them to inspect each page and decide whether margins should be applied to the entire document or only to specific pages.

In this project, every page is rendered as a thumbnail. Users can quickly scroll through the document and verify page order before adjusting any settings.

For large documents, thumbnail previews make navigation much easier than displaying one full-size page at a time.

The browser renders each page directly from the uploaded PDF without sending the document to a server.

After loading the document, each page can be rendered individually.

const pdfDoc = await PDFDocument.load(pdfBytes);

const pages = pdfDoc.getPages();

console.log("Total Pages:", pages.length);

Each page is then displayed inside the preview gallery.

pages.forEach((page, index) => {

    console.log(`Rendering page ${index + 1}`);

});

After the previews are generated, users can move on to configuring the margin settings.

Preview Demo

Configuring Margin Settings

After verifying the uploaded document, users can configure exactly how the margins should be added.

Rather than applying one fixed margin to every document, the tool provides several options that make it suitable for different printing, publishing, and business workflows.

Users can enter custom values for the top, bottom, left, and right margins. These values can be measured in millimeters, pixels, or inches depending on the intended use.

For users who don't want to calculate measurements manually, the application also includes preset margin sizes such as None, Narrow, Normal, and Wide.

The tool supports applying margins to every page or only to a specific page range. This is especially useful when only certain pages require additional spacing.

For printed books and manuals, mirror margins can be enabled so that left and right pages automatically receive opposite inner margins for binding.

Users can also decide how the margin should be applied. Expanding the page size preserves the original content dimensions while increasing the overall page size. Alternatively, the existing page size can be maintained and the content repositioned within the available space.

All of these settings are configured before any processing begins, allowing users to preview and adjust everything in advance.

Example margin configuration:

const marginSettings = {

    top: 25.4,

    bottom: 25.4,

    left: 25.4,

    right: 25.4,

    unit: "mm",

    applyTo: "all",

    mirrorMargins: false,

    preset: "Normal",

    resizeMode: "Expand Page Size"

};

The selected values are then used while generating the updated PDF pages.

Margin Settings Demo

Applying the Margins

Once the margin settings have been configured, the application can begin processing the PDF.

Instead of modifying the original document directly, the tool creates a new page layout based on the selected margin values. The existing page content is then repositioned inside the newly calculated page dimensions.

This approach preserves the original document while generating a new PDF with additional white space around the content.

Depending on the selected resize mode, the application can either expand the page size to accommodate the new margins or keep the existing page size and reposition the content within the available printable area.

For documents containing multiple pages, the same settings can be applied to every page or only to a selected page range.

A simplified example looks like this:

const pages = pdfDoc.getPages();

pages.forEach((page) => {

    const { width, height } = page.getSize();

    const newWidth = width + leftMargin + rightMargin;

    const newHeight = height + topMargin + bottomMargin;

    page.setSize(newWidth, newHeight);

});

The application then adjusts the page content so it remains correctly positioned inside the new page dimensions.

page.translateContent(
    leftMargin,
    bottomMargin
);

This ensures the document content shifts into the correct position while leaving the requested space around the page edges.

Applying Margins Demo

Generating the Updated PDF

After every selected page has been processed, the browser creates a brand-new PDF containing the updated page sizes and margin layout.

The original PDF remains unchanged while the modified document is prepared for download.

Because everything happens locally, the generation process is usually very fast, even for multi-page documents.

Once processing is complete, the updated PDF is converted into downloadable bytes.

const pdfBytes = await pdfDoc.save();

A Blob object can then be created for downloading.

const blob = new Blob(
    [pdfBytes],
    {
        type: "application/pdf"
    }
);

const url = URL.createObjectURL(blob);

Finally, the browser starts the download.

const link = document.createElement("a");

link.href = url;

link.download = "updated-document.pdf";

link.click();

The generated PDF can also be previewed before downloading.

Users are able to review the updated document, rename the output file, view the total number of pages, check the final file size, and download the completed PDF when they are satisfied with the results.

Updated PDF Preview

Demo: How the Add Margins Tool Works

Step 1: Upload Your PDF File

The process begins by uploading a PDF document using either the drag-and-drop area or the file picker.

Once a file is selected, the browser validates that it's a PDF and loads it locally. Since all processing happens inside the browser, the document never leaves the user's device, making the tool suitable for confidential reports, contracts, invoices, and other sensitive documents.

After the file is loaded successfully, the application prepares the document for preview generation and margin editing.

Step 2: Preview Uploaded PDF Pages

After uploading the document, the application generates page previews directly inside the browser.

Displaying page thumbnails allows users to verify that the correct document has been selected before making any changes. For larger PDFs, the preview section also makes it easier to navigate through the document and inspect individual pages.

This step helps prevent mistakes before the margin settings are applied.

Step 3: Configure Margin Settings

Next, users configure how margins should be added to the document.

The tool allows custom values for the top, bottom, left, and right margins while also supporting predefined presets such as None, Narrow, Normal, and Wide.

Users can choose whether the margins should be applied to every page or only to selected page ranges. Mirror margins are available for printed books and documents that require binding.

Another useful option lets users decide whether the application should expand the overall page size or reposition the existing content while keeping the original page dimensions.

These settings provide complete control over how the final document will appear.

Step 4: Apply the Margins

After reviewing the selected settings, users simply click the Add Margins button.

The browser processes every selected page, calculates the new page dimensions, repositions the original content, and generates an updated PDF with the requested spacing around each page.

If users want to work with another document, the Start Over button clears the current session without requiring a page refresh.

Step 5: Preview the Updated PDF

Once processing has finished, the updated document is displayed inside the browser.

Users can review every page before downloading to ensure the margins have been applied correctly.

The preview section also includes page navigation controls, making it easy to browse through multi-page documents and confirm that every selected page has been processed successfully.

Reviewing the document before downloading helps catch formatting issues early and reduces the need for additional edits later.

Step 6: Download the Final PDF

After verifying the updated document, users can download the finished PDF.

The final output section displays useful information including the output filename, total number of pages, and file size. Users can rename the generated document before downloading it, making file organization much easier.

Once everything looks correct, the updated PDF can be downloaded and immediately used for printing, sharing, binding, archiving, or submitting to organizations that require specific page margins.

Important Notes from Real-World Use

Adding margins is generally a lightweight operation, but large PDF files containing hundreds of pages or high-resolution images may require additional processing time.

Before processing begins, it's a good idea to validate the uploaded file.

if (file.type !== "application/pdf") {
    alert("Please upload a valid PDF file.");
    return;
}

When working with large documents, verify the selected margin values before generating the final PDF.

console.log(`Top: ${topMargin}`);
console.log(`Bottom: ${bottomMargin}`);
console.log(`Left: ${leftMargin}`);
console.log(`Right: ${rightMargin}`);

If the document is intended for printing, preview the generated PDF to ensure that text, tables, images, and page numbers remain correctly positioned.

Because all processing happens locally, documents remain on the user's device throughout the entire workflow, making browser-based margin editing suitable for contracts, invoices, financial reports, legal documents, educational records, healthcare forms, and other confidential PDFs.

Common Mistakes to Avoid

One common mistake is using excessively large margin values that reduce the printable area more than necessary.

Always verify the selected measurements before generating the updated document.

if (leftMargin < 0 || rightMargin < 0) {
    alert("Margin values cannot be negative.");
}

Another mistake is forgetting to choose the correct page selection mode.

Sometimes only the first page or a specific page range requires additional margins, while the rest of the document should remain unchanged.

const applyTo = "all";

console.log(`Apply margins to: ${applyTo}`);

Users should also verify whether Expand Page Size or Keep Original Page Size is the correct option for their workflow. Choosing the wrong mode can affect the final layout when printing or sharing the document.

Finally, always review the generated PDF before downloading it.

Taking a few moments to inspect the updated pages helps confirm that the spacing is correct, page content remains properly aligned, and the document is ready for printing, binding, archiving, or distribution.

Conclusion

In this tutorial, you built a browser-based PDF Add Margins Tool using JavaScript.

You learned how to upload PDF files, preview document pages, configure custom margin settings, apply margins to selected pages, and generate updated PDF files directly inside the browser.

More importantly, you saw how modern browsers can perform PDF page layout modifications without requiring a backend server.

This approach keeps document processing fast, private, and easy to use while giving users complete control over page spacing.

You can try the live implementation here: AllInOneTools - Add Margin to PDF.

Once you understand this workflow, you can extend it further by adding features such as page cropping, resizing, page numbering, watermarking, document organization, metadata editing, and other advanced PDF editing capabilities.

How to Build a Zero-Cost Personal Project with PHP, Wasmer, and Cloudflare

Jakub T. Jankiewicz — Wed, 01 Jul 2026 15:43:55 +0000

Recently, I wanted to reinvigorate my open-source project Clarity, an icon theme for Linux (GTK+).

The icons allow users to create custom colors by adding SVG templates. And I wanted to have a platform where users would be able to submit their own custom templates for the icons.

The problem is that if I create a new website for my project that requires recurring payment, and I'm no longer alive, the website will disappear. So to keep it going in perpetuity, I needed a free domain and free hosting. I decided to use PHP for this new project.

In this article, I'll show you step by step how to:

Get a free .eu.org domain.
Set up name servers on Cloudflare.
Set up hosting on Wasmer.
Glue everything together.

Requirements
About Wasmer
What is DNS?
How to Create a Wasmer Account?
How to Create a Wasmer PHP Project?
How to Set Up Cloudflare?
How to Register an eu.org Domain?
Conclusion

Requirements

For this article, I assume that you already have a GitHub account and know how to create Git repositories. You should also have a Cloudflare account. The code uses PHP, but you don't need to know it to go through this tutorial. Wasmer supports other languages and frameworks that you can use instead if you like.

About Wasmer

First, let me explain how hosting works with Wasmer. You may have had problems with hosting tools that take too long to wake up your project when it hasn't been used for a while. Well, you'll be happy to learn that in Wasmer, a cold start takes less than 90 milliseconds.

Applications on Wasmer are stateless, so if you want to keep user data, you'll need a persistent store. It natively supports cloud MySQL instances and network protocols for external PostgreSQL and MySQL/MariaDB, as well as file-based SQLite through persistent volumes.

Wasmer also supports Python, Rust, PHP, and Node.js, and it plans to support GoLang soon, too.

You can host applications in Django, Flask, FastAPI, WordPress, Symfony, Laravel, Next.js, Nuxt, Hugo, Astro, Vite, and others as well, so you have lots of options.

The platform also supports CGI, which allows you to use any language that compiles to a binary executable like Rust, C, or C++.

What is DNS?

Now is a good time to explain what DNS is. DNS stands for Domain Name System, and it's a way to translate human-readable names like freecodecamp.org to the IP address of a server where the website or web app is located.

In short, the system works like a tree of servers. At the root there's the Root Server, which directs your request to the TLD (Top-Level Domain) Server responsible for .org extensions.

This TLD server points to the specific Authoritative Name Server of the domain. A Name Server is a specialized server that acts as a storage folder for a domain's official DNS records, telling the internet exactly where to find the website's assets.

Inside these records, you'll find different types of pointers. One common type is the CNAME record (Canonical Name). Instead of pointing a domain directly to an IP address, a CNAME record acts as an alias that maps one domain name to another domain name. For example, it can forward www.freecodecamp.org to the root freecodecamp.org.

How to Create a Wasmer Account

Let's jump in and create a Wasmer account so we can get started. To do this, you need to go to wasmer.io and pick the Hobby plan:

Then create an account:

The simplest way forward is to connect to your GitHub:

After you authorize via GitHub, you should be logged in and see your avatar in the top right corner:

How to Create a Wasmer PHP Project

First, you need to create a new GitHub repository for your PHP project. For this tutorial, I created one with a simple index.php file that shows my new domain name (I'll show you how to register the domain name in a bit).

After you commit the file, this is how your repo should look on GitHub:

This was my repository: https://github.com/jcubic/Clarity-icons. But then I decided to add the website as part of my main repo.

After you create a GitHub account, you have to tell Wasmer about it. To do this, you need to add a Wasmer GitHub account. Create a new project and click "Add GitHub Account":

You should see a popup where you can select the account where you want to install the Wasmer app. If you're not part of any organization on GitHub, you should see only your own GitHub profile. Select that one.

It should redirect you to GitHub, where you can either provide access to all repositories or pick the one you want. I usually just give access to specific repositories. So I've selected my new repo here:

After you set up permissions, you'll need to import the app into Wasmer:

After you click import, you can set up some details about your project like the owner, project link, and so on:

After you click "Deploy", you'll need to wait awhile for deployment to happen:

When it finishes, you should see this celebration page with confettii:

When you go to the dashboard, you should see that the app is running:

This is how the website looks live:

In the settings, you can see how to add a custom domain (that we'll set up in a minute).

It shows the CNAME DNS record that you need to include in order for the custom domain to work properly.

How to Set Up Cloudflare

Next, we'll set up Cloudflare, which allows you to manage DNS. We'll keep our new domain there.

After you create a Cloudflare account, you'll need to go into the domain overview section:

Click "Add domain" and pick "Connect a domain":

Then you need to name your domain:

Then pick the Free plan:

After you create your domain (you'll need to wait a few seconds), you can set up DNS records (we already have the CNAME from Wasmer).

Add a new CNAME record from Wasmer:

After you click "Continue activation" you should see this page with two nameservers:

We'll use those two domain names when we register the eu.org domain.

How to Register an eu.org Domain

To create a .eu.org domain, you first have to create an account. For this, you'll need to visit https://nic.eu.org/arf/en/contact/create/ and fill in the details, like your address and a phone number. That type of information is required for any domain you register.

In the above screenshot, I've added "Fax" instead of "Phone". I corrected that later. You can always edit the information if you make a mistake.

After you click create, you should see this page showing that you successfully created your contact page:

After you validate your email (click the activation link), you should see this page stating that your contact handle is now valid:

After you log in, you'll see a form where you can add domains:

Then just click and select a domain name.

I initially picked the clarity-icons.eu.org domain, but on the page https://nic.eu.org/opendomains.html, they don't recommend using a .eu.org directly. Instead, they recommend picking one of the subdomains (an additional prefix name with a dot). I've picked .pl.eu.org since I'm from Poland.

The process of creating a .eu.org can take a few days. I registered an account on the 1st of June and got the below email on the 6th of June. So a week is a safe bet.

The domain appeared after about 24 hours.

I've checked the next day, and my domain, clarity.pl.eu.org was up.

Conclusion

Creating a sustainable website for your open-source project that will remain long after you're gone is possible. This type of setup is also great for small personal projects.

If you have any questions, you can contact me on Twitter/X, my DMs are open. You can also check out my personal blog.

How to Build a Text Compare Tool with HTML, CSS, and JavaScript

Bansidhar Kadiya — Wed, 01 Jul 2026 15:36:17 +0000

Have you ever tried to spot the differences between two long paragraphs of text? Reading line-by-line to find a missing word or a new sentence is a massive headache.

In this tutorial, you'll build your very own browser-based Text Compare Tool. It will take an original piece of text, compare it against a changed version, and instantly highlight exactly what was added or removed.

Building this project will help you level up your JavaScript skills. You'll also create a tool that's highly secure, because everything happens locally in the user's browser. No sensitive data is ever sent to a server.

Let’s get started.

Prerequisites

To follow along easily, you should know:

Basic HTML and CSS knowledge: How to structure a page and use Flexbox to put items side-by-side.
Basic JavaScript knowledge: How to write functions, use arrays, and listen for button clicks.
Your Setup: A code editor (like VS Code) and a web browser to view your work.

Step 1: Set Up Your Project Files
Step 2: Build the HTML Structure
Step 3: Style the Tool with CSS
Step 4: Write the JavaScript Engine
Step 5: Test Your Application
Conclusion

Step 1: Set Up Your Project Files

First, you need a place to store your code. Create a new folder on your computer and name it text-compare-tool.

Inside that folder, create three empty files:

index.html (This holds the structure of your app)
style.css (This makes your app look good)
script.js (This makes your app actually work)

Step 2: Build the HTML Structure

Open your index.html file. You need to create a simple layout with two large text boxes: one for the original text, and one for the updated text.

Copy and paste this code into your HTML file:




    
    
    Text Compare Tool
    



    Text Compare Tool
    
        Quickly find every addition and deletion between two versions of your text. Just paste them into our tool, and we’ll show you exactly what’s been changed.

Understanding the HTML:

The two panels: Inside the .panels-wrapper, you have a left side and a right side.
Textareas vs results: Each side has a </code> where the user can type. Right below the text area is a <code><div></code> with the class <code>.result-box</code>. Right now, those result boxes are invisible. Later, JavaScript will hide the text areas and show the result boxes instead. </li> <li>The buttons: The "Compare" and "Clear" buttons are hooked up to JavaScript functions using <code>onclick</code>. </li> </ul> <h2 id="heading-step-3-style-the-tool-with-css">Step 3: Style the Tool with CSS</h2> A good utility tool should be easy on the eyes. You'll use a clean white and blue design, and apply soft red and green colors to highlight the text changes. Open your <code>style.css</code> file and add this code: <pre><code class="language-css">:root { --primary-blue: #007bff; --background-color: #f8f9fa; --text-color: #202124; --border-color: #dadce0; /* Highlight Colors */ --red-bg: #fce8e6; --red-text: #c5221f; --green-bg: #e6f4ea; --green-text: #137333; } body { font-family: Arial, sans-serif; background-color: var(--background-color); color: var(--text-color); display: flex; flex-direction: column; align-items: center; padding: 40px 20px; margin: 0; } h1 { margin-bottom: 10px; } .description { text-align: center; max-width: 600px; color: #5f6368; margin-bottom: 30px; line-height: 1.5; } .container { background: white; padding: 20px; border-radius: 8px; border: 1px solid var(--border-color); width: 100%; max-width: 1000px; box-shadow: 0 4px 10px rgba(0,0,0,0.05); } .panels-wrapper { display: flex; gap: 20px; margin-bottom: 20px; } .panel { flex: 1; display: flex; flex-direction: column; } textarea, .result-box { width: 100%; height: 300px; padding: 15px; border: 1px solid var(--border-color); border-radius: 6px; font-size: 16px; line-height: 1.5; box-sizing: border-box; resize: vertical; } textarea:focus { outline: none; border-color: var(--primary-blue); } /* Hidden by default */ .result-box { display: none; background-color: #fafafa; overflow-y: auto; white-space: pre-wrap; } .controls { display: flex; justify-content: center; gap: 15px; } button { padding: 10px 25px; font-size: 16px; font-weight: bold; border: none; border-radius: 5px; cursor: pointer; } .btn-compare { background-color: var(--primary-blue); color: white; } .btn-clear { background-color: white; color: var(--primary-blue); border: 1px solid var(--border-color); } /* How the differences will look */ .deleted { background-color: var(--red-bg); color: var(--red-text); padding: 2px 4px; border-radius: 3px; } .added { background-color: var(--green-bg); color: var(--green-text); padding: 2px 4px; border-radius: 3px; } </code></pre> Understanding the CSS: <ul> <li>Flexbox layout: <code>display: flex;</code> inside <code>.panels-wrapper</code> is what places your two text boxes neatly side-by-side. </li> <li>The highlighters: The <code>.deleted</code> and <code>.added</code> classes are the most important part of the visual design. When a user deletes a word, we give it a soft red background. When they add a word, it gets a soft green background. </li> </ul> This is what your tool will look like once it's finished: <h2 id="heading-step-4-write-the-javascript-engine">Step 4: Write the JavaScript Engine</h2> Now you need to make the tool actually work. How does your computer know if a word has changed? We have to write logic that breaks paragraphs down into individual words. The code will look at the original list of words and compare it to the new list. If a word from the original text is missing, it gets marked as "deleted." If a brand new word appears, it gets marked as "added." Open your <code>script.js</code> file and paste in this complete, working code: <pre><code class="language-javascript">function compareText() { // 1. Grab the text from the text boxes const text1 = document.getElementById('text1').value; const text2 = document.getElementById('text2').value; // 2. Chop the text up into an array of words (and keep the spaces) const words1 = text1.split(/(\s+)/); const words2 = text2.split(/(\s+)/); // 3. Find the differences const { diff1, diff2 } = calculateDifferences(words1, words2); const resultBox1 = document.getElementById('result1'); const resultBox2 = document.getElementById('result2'); // 4. Turn those differences into HTML with colors resultBox1.innerHTML = createColoredHTML(diff1, 'deleted'); resultBox2.innerHTML = createColoredHTML(diff2, 'added'); // 5. Hide the text boxes and show the final results document.getElementById('text1').style.display = 'none'; document.getElementById('text2').style.display = 'none'; resultBox1.style.display = 'block'; resultBox2.style.display = 'block'; } // The engine that compares the two lists of words function calculateDifferences(arr1, arr2) { const n = arr1.length; const m = arr2.length; // Create a grid to keep track of matching words const grid = Array.from({ length: n + 1 }, () => Array(m + 1).fill(0)); for (let i = 1; i <= n; i++) { for (let j = 1; j <= m; j++) { if (arr1[i - 1] === arr2[j - 1]) { grid[i][j] = grid[i - 1][j - 1] + 1; } else { grid[i][j] = Math.max(grid[i - 1][j], grid[i][j - 1]); } } } let i = n, j = m; const diff1 = []; const diff2 = []; // Walk backwards through the grid to mark what changed while (i > 0 || j > 0) { if (i > 0 && j > 0 && arr1[i - 1] === arr2[j - 1]) { diff1.unshift({ value: arr1[i - 1], type: 'equal' }); diff2.unshift({ value: arr2[j - 1], type: 'equal' }); i--; j--; } else if (j > 0 && (i === 0 || grid[i][j - 1] >= grid[i - 1][j])) { diff2.unshift({ value: arr2[j - 1], type: 'changed' }); j--; } else if (i > 0 && (j === 0 || grid[i][j - 1] < grid[i - 1][j])) { diff1.unshift({ value: arr1[i - 1], type: 'changed' }); i--; } } return { diff1, diff2 }; } // Packages the text safely into HTML span elements function createColoredHTML(diffArray, colorClass) { return diffArray.map(wordItem => { // Replace dangerous characters so the browser doesn't crash const safeText = wordItem.value.replace(/</g, "<").replace(/>/g, ">"); // If the word was changed (and isn't just a blank space), wrap it in color if (wordItem.type === 'changed' && !/^\s+$/.test(wordItem.value)) { return `${safeText}`; } return safeText; }).join(''); } // Puts the tool back to its default state function clearText() { document.getElementById('text1').value = ''; document.getElementById('text2').value = ''; document.getElementById('text1').style.display = 'block'; document.getElementById('text2').style.display = 'block'; document.getElementById('result1').style.display = 'none'; document.getElementById('result2').style.display = 'none'; } </code></pre> Understanding the JavaScript: <ol> <li>Keeping the formatting: In the first function, you see <code>.split(/(\s+)/)</code>. This splits the text up by spaces, but keeps the spaces and line-breaks. If you don't do this, all of the user's paragraphs will mash into one giant block of text! </li> <li>The grid system: The <code>calculateDifferences</code> function creates an invisible grid. It compares every word in the first box with every word in the second box. If it sees the same word in the same order, it leaves it alone. If it hits a snag, it marks the word as a change. </li> <li>Safety first: The <code>createColoredHTML</code> function wraps our changed words in <code></code> or <code></code> so CSS can color them. But before it does that, it removes any <code><</code> or <code>></code> symbols using <code>.replace()</code>. This stops hackers from pasting malicious code into your app. </li> </ol> <h2 id="heading-step-5-test-your-application">Step 5: Test Your Application</h2> You're completely done coding! Now it’s time to see it in action. <ol> <li>Open your <code>text-compare-tool</code> folder. </li> <li>Double-click the <code>index.html</code> file. It will open in your default web browser. </li> <li>Type a sentence into the left box: "The quick brown fox jumps over the lazy dog." </li> <li>Type a slightly different sentence into the right box: "The fast brown fox jumps over the sleepy dog." </li> <li>Click Compare. </li> </ol> You will instantly see the word "quick" highlight in red on the left, and the word "fast" highlight in green on the right. If you want to start over, just click Clear. <h2 id="heading-conclusion">Conclusion</h2> Great job! You just built a highly practical, browser-based text comparison utility using nothing but pure HTML, CSS, and JavaScript. You learned how to break text into arrays, compare them using a grid-based algorithm, and manipulate the DOM to show those differences to the user safely. Because this tool relies on local browser processing, it's incredibly fast and 100% private. If you want to see this exact logic running in a live production environment, or if you need to bookmark a fast tool for your own writing tasks, check out the live <a href="https://99tools.net/text-compare-tool/">Text Compare Tool</a>. Keep experimenting with the code, and happy building! </article> <article> <h1> How to Use the Screen Reader That's Built into Your iPhone </h1> Ilknur Eren — Tue, 30 Jun 2026 20:47:19 +0000 Every iPhone and iPad includes a built-in screen reader called VoiceOver. VoiceOver speaks aloud the text on the screen, app names, icons, buttons, menus, links, and notifications and alerts. These accessibility features are crucial for users who may be blind, have low vision, or have reading differences. As a developer, it's always important to manually test your website for accessibility. A screen reader is one of the most important tools to add to your testing process. Even small issues, like a button with no label or an image with no alt text, can make a page completely unusable for someone relying on VoiceOver. As you test on an actual device with VoiceOver, you may find accessibility issues you didn’t know you had. In this tutorial, we'll cover how to turn VoiceOver on, the basic gestures to know, and how to adjust its settings to fit your needs. <h3 id="heading-what-well-cover">What We'll Cover:</h3> <ul> <li><a href="#heading-how-to-turn-on-voiceover">How to turn on VoiceOver</a> <ul> <li><a href="#heading-option-1-use-settings">Option 1: Use Settings</a> </li> <li><a href="#heading-option-2-use-siri">Option 2: Use Siri</a> </li> <li><a href="#heading-option-3-set-up-the-accessibility-shortcut">Option 3: Set up the Accessibility Shortcut</a> </li> </ul> </li> <li><a href="#heading-basic-gestures-to-know">Basic Gestures to Know</a> </li> <li><a href="#heading-how-to-adjust-voiceover-settings">How to Adjust VoiceOver Settings</a> <ul> <li><a href="#heading-change-the-speaking-rate">Change the Speaking Rate</a> </li> <li><a href="#heading-change-the-voice">Change the Voice</a> </li> </ul> </li> <li><a href="#heading-conclusion">Conclusion</a> </li> </ul> <h2 id="heading-how-to-turn-on-voiceover">How to Turn On VoiceOver</h2> There are a few ways to turn VoiceOver on or off. As you practice, you might lean toward one option over the others. <h3 id="heading-option-1-use-settings">Option 1: Use Settings</h3> <ol> <li>Open the Settings app. </li> <li>Tap Accessibility. </li> <li>Tap VoiceOver. </li> <li>Toggle it on or off. </li> </ol> In the Accessibility Settings section, you can also find other accessible settings to explore — including Display & Text Size, Motion, and Spoken Content. It's worth browsing through to understand what tools are available to users. <h3 id="heading-option-2-use-siri">Option 2: Use Siri</h3> To turn on VoiceOver using Siri, say: "Hey Siri, turn on VoiceOver." To turn it off, say: "Hey Siri, turn off VoiceOver." Using Siri might be the easiest way to turn VoiceOver on or off for beginners. If you accidentally turn VoiceOver on and don't yet know any shortcuts or gestures, just ask Siri. Siri works independently of VoiceOver gestures, so it's a reliable fallback when you feel stuck. <h3 id="heading-option-3-set-up-the-accessibility-shortcut">Option 3: Set Up the Accessibility Shortcut</h3> If you find yourself turning VoiceOver on and off frequently, setting up the Accessibility Shortcut makes sense. This is the quickest method for developers who are regularly switching VoiceOver on to test and off to work. It lets you toggle VoiceOver by pressing the side button three times. <ol> <li>Go to Settings > Accessibility. </li> <li>Scroll down and tap Accessibility Shortcut. </li> <li>Select VoiceOver. </li> </ol> After that, press the side button (or Home button on older iPhones) three times to toggle VoiceOver on or off. If you have more than one accessibility feature enabled in the shortcut, your iPhone will show a menu to pick from instead of toggling automatically. <h2 id="heading-basic-gestures-to-know">Basic Gestures to Know</h2> When VoiceOver is on, the way you touch the screen changes what the phone interprets. The same swipe or tap that normally opens an app does something different with VoiceOver active. Here are the five core gestures every developer should learn first: <ul> <li>Swipe right: Move to the next item on screen </li> <li>Swipe left: Move to the previous item on screen </li> <li>Swipe up or down with three fingers: Scroll up or down the page </li> <li>One tap: Hear VoiceOver read the item aloud </li> <li>Double-tap: Open an app or activate a button </li> </ul> Tip: When you first tap an item, VoiceOver reads it to you. Then you can double-tap to actually open or activate it. This two-step process helps you confirm you're on the right element before you act. This is especially useful when testing unfamiliar interfaces. These five gestures are the foundation. As you use VoiceOver more frequently, they'll become second nature. Once you're comfortable, you can explore more advanced gestures like the VoiceOver rotor, which lets you navigate by headings, links, form fields, and more. For the time being, if you're comfortable with these five gestures, you’ll be able to test mobile accessibility issues for your products. <h2 id="heading-how-to-adjust-voiceover-settings">How to Adjust VoiceOver Settings</h2> You can change how VoiceOver sounds and behaves to better suit your testing workflow or personal preferences. <h3 id="heading-change-the-speaking-rate">Change the Speaking Rate</h3> <ol> <li>Go to Settings > Accessibility > VoiceOver. </li> <li>Use the Speaking Rate slider to make it faster or slower. </li> </ol> You can also adjust the speaking rate with the VoiceOver rotor. Rotate two fingers on the screen until you hear “Speaking Rate,” then swipe up or down with one finger to make VoiceOver faster or slower. This changes the rate on the fly without going into Settings. It's handy when you want to slow down while exploring a complex page or speed up when navigating familiar content. Experienced VoiceOver users often run the speaking rate very fast. Don't be surprised if the default speed feels quick. You can always slow it down while you're learning. <h3 id="heading-change-the-voice">Change the Voice</h3> If you want to change the voice or language, Go to Settings > Accessibility > VoiceOver > Speech. From there, you can choose a different VoiceOver voice, add rotor voices for other languages, or enable language detection. Apple offers multiple voice options across many languages. This is useful when testing multilingual content, but make sure your site also uses correct <code>lang</code> attributes so screen readers can switch pronunciation appropriately. <h2 id="heading-conclusion">Conclusion</h2> As a developer, it's always important to manually test your website for accessibility. Testing it with the accessibility features your users use is crucial to access the product through their lens and fix accessibility bugs the product might have. Simply turning the VoiceOver on and learning about these five simple gestures will give you the tools to audit and test your website for accessibility issues. </article> <article> <h1> How to Stop Your AI Coding Agent from Writing Outdated Code with Modern Web Guidance </h1> Ophy Boamah — Wed, 24 Jun 2026 23:19:25 +0000 AI coding agents can save developers a lot of time – that is, until you open the output and realize they've written code like it's 2019. Ask an agent to build a tooltip, for example. The HTML looks polished, the CSS transitions are smooth, the <code>aria-describedby</code> wiring is correct. Then you get to the JavaScript: a <code>js-hidden</code> class toggle system, a <code>dismissAllTooltips()</code> function, touch event handlers, click-outside detection, and an entire interaction management layer to compensate for what CSS alone can't do. The agent isn't broken. It's just reaching for patterns that dominate its training data, even though the browser has had better answers for years. Modern Web Guidance (MWG) is Google Chrome's open-source fix. It injects expert-vetted, platform-aware guidance directly into your AI agent's context, steering it toward current, accessible, and performant web standards. In this article, you'll learn why Modern Web Guidance solves the "legacy code" problem, and how to integrate it into your workflow for consistently up-to-date results. <h3 id="heading-table-of-contents">Table of Contents:</h3> <ul> <li><a href="#heading-why-do-ai-agents-default-to-legacy-patterns">Why Do AI Agents Default to Legacy Patterns?</a> </li> <li><a href="#heading-what-is-modern-web-guidance-mwg">What Is Modern Web Guidance (MWG)?</a> </li> <li><a href="#heading-how-to-install-modern-web-guidance">How To Install Modern Web Guidance</a> </li> <li><a href="#heading-after-installing-modern-web-guidance-what-actually-changes">After Installing Modern Web Guidance: What Actually Changes</a> </li> <li><a href="#heading-what-modern-web-guidance-does-not-handle-for-you">What Modern Web Guidance Does Not Handle for You</a> </li> <li><a href="#heading-conclusion">Conclusion</a> </li> </ul> <h2 id="heading-why-do-ai-agents-default-to-legacy-patterns">Why Do AI Agents Default to Legacy Patterns?</h2> Every large language model (LLM) learns from the web, which is evolving at a truly rapid pace. New browser APIs ship years before they have enough tutorials, Stack Overflow answers, and real-world codebases to meaningfully appear in training data. The practical result: even when a model has been trained to know that a modern API exists, it has seen the old approach thousands of times and the new approach a handful of times. As a result, when it generates code, the legacy pattern wins, not because the model is ignorant, but because the training signal for the outdated approach is stronger. Prompting doesn't fully solve this. Telling your agent to "use modern APIs" nudges things slightly, but it doesn't provide the dense, expert-vetted implementation patterns the model needs to write production-ready modern code confidently. You'd have to paste in documentation for every feature, in every session, indefinitely. Here's what the problem looks like in practice. To have real outputs to test, I prompted Antigravity IDE to build two separate components without Modern Web Guidance installed. <h3 id="heading-before-tooltip-component">Before: Tooltip Component</h3> Prompt: "Build a tooltip component that appears above a button when hovered." The HTML is reasonable. The CSS handles positioning with <code>position: absolute</code>, animates opacity, and even wires up <code>role="tooltip"</code> and <code>aria-describedby</code> correctly. Then you get to the JavaScript: <pre><code class="language-javascript">// ❌ Before MWG — a full interaction management layer built in JS document.addEventListener('DOMContentLoaded', () => { const containers = document.querySelectorAll('.tooltip-container'); containers.forEach(container => { const trigger = container.querySelector('.tooltip-trigger'); const tooltip = container.querySelector('.tooltip-content'); const forceHide = () => tooltip.classList.add('js-hidden'); const resetVisibility = () => tooltip.classList.remove('js-hidden'); // Escape key to dismiss trigger.addEventListener('keydown', (e) => { if (e.key === 'Escape') { forceHide(); e.preventDefault(); } }); trigger.addEventListener('blur', resetVisibility); container.addEventListener('mouseleave', resetVisibility); container.addEventListener('mouseenter', resetVisibility); // Touch handling trigger.addEventListener('touchstart', (e) => { const isVisible = !tooltip.classList.contains('js-hidden') && getComputedStyle(tooltip).visibility === 'visible'; if (isVisible) { forceHide(); } else { dismissAllTooltips(); resetVisibility(); } }, { passive: true }); }); function dismissAllTooltips() { document.querySelectorAll('.tooltip-content').forEach(t => t.classList.add('js-hidden')); } document.addEventListener('click', (e) => { if (!e.target.closest('.tooltip-container')) { document.querySelectorAll('.tooltip-content').forEach(t => t.classList.remove('js-hidden')); } }); }); </code></pre> The problem isn't that the above code is wrong – not at all, it works. The problem is what it reveals: because the CSS <code>:hover</code> and <code>:focus-within</code> selectors can't handle Escape-to-dismiss, touch toggle, or click-outside detection, the agent has to build a parallel JavaScript system to manage tooltip state. Visibility is now split across two systems that have to stay in sync. A <code>js-hidden</code> class exists specifically to let JavaScript override CSS. You can move ahead to <a href="#heading-after-tooltip-component">see the updated Tooltip component code after Modern Web Guidance was installed</a> if you're curious right now. Next, let's look at how the agent builds a toast notification without Modern Web Guidance. <h3 id="heading-before-toast-notification-with-exit-animation">Before: Toast Notification with Exit Animation</h3> Prompt: "Build a toast notification system where notifications fade out before being removed." <pre><code class="language-javascript">// ❌ Before MWG — JavaScript owns the entire animation lifecycle const dismissToast = (toast) => { if (toast.classList.contains('toast-fade-out')) return; // 1. Apply fade-out class to trigger CSS transition toast.classList.add('toast-fade-out'); // 2. Wait for transition, then remove from DOM const handleUnmount = (e) => { if (e.propertyName === 'opacity' || e.propertyName === 'transform') { toast.removeEventListener('transitionend', handleUnmount); toast.remove(); } }; toast.addEventListener('transitionend', handleUnmount); // 3. Fallback in case transitionend doesn't fire setTimeout(() => { if (toast.parentNode) toast.remove(); }, 400); }; // Auto-dismiss after 4 seconds autoDismissTimer = setTimeout(() => { dismissToast(toast); }, 4000); </code></pre> Reviewing the code above: this pattern is extremely common, and again it does work. But notice how much JavaScript is dedicated to a problem that's fundamentally about animation timing. The agent adds a CSS class to start a transition, then uses <code>transitionend</code> to know when to remove the element, then adds a <code>setTimeout</code> fallback in case <code>transitionend</code> doesn't fire, then another <code>setTimeout</code> for auto-dismissal. The JavaScript and CSS are deeply entangled. Change the transition duration in CSS and you have to update the JavaScript timeout to match. You can move ahead to <a href="#heading-after-toast-notification-with-exit-animation">see the updated Toast notification code after Modern Web Guidance was installed</a> if you're curious now. Both examples share the same shape: the agent writes JavaScript to compensate for what it doesn't know the browser can handle natively. <h2 id="heading-what-is-modern-web-guidance-mwg">What Is Modern Web Guidance (MWG)?</h2> <a href="https://developer.chrome.com/docs/modern-web-guidance">Modern Web Guidance</a> is an open-source project backed by the Google Chrome team and the Microsoft Edge team. Instead of hoping the model knows what the modern platform offers, you give it a structured, expert-vetted reference file that maps common development scenarios to the right solutions. It ships as an agent skill, a <code>SKILL.md</code> file that lives in your project and gets read by your coding agent before it generates code. Think of it as a project-specific instruction manual that teaches the agent which modern APIs exist and when to use them. The skill shifts the probability distribution toward modern platform solutions in a way that a one-line prompt instruction can't. Under the hood, the mechanism works in three steps: <ol> <li>Your agent activates the skill because the task is web-related. </li> <li>The agent runs <code>modern-web-guidance search "<query>"</code>, a local semantic search using an offline TensorFlow.js model. No API key, and no network call. </li> <li>The agent retrieves the matched guide via <code>modern-web-guidance retrieve <guide-id></code>, injecting targeted patterns, gotchas, and fallback strategies directly into its context window. </li> </ol> Two skill packs are available. <code>modern-web-guidance</code> covers modern browser APIs, CSS layout systems, performance, accessibility, and built-in AI APIs. This is what most developers want. <code>chrome-extensions</code> covers Manifest V3, background workers, and Chrome Web Store publishing. <a href="https://developer.chrome.com/docs/modern-web-guidance/get-started#how_is_accuracy_ensured">Early evals show a 37 percentage point improvement</a> in adherence to modern best practices when agents run with it installed. <h2 id="heading-how-to-install-modern-web-guidance">How to Install Modern Web Guidance</h2> The universal path (works with any agent): <pre><code class="language-shell">npx modern-web-guidance@latest install </code></pre> This runs an interactive wizard that detects your coding agent, asks which skill packs you want, and drops the <code>SKILL.md</code> file in the correct location automatically. The CLI is fully offline and self-contained: no external dependencies and no API keys. Claude Code: <pre><code class="language-shell">#1. Add the marketplace /plugin marketplace add GoogleChrome/modern-web-guidance #2. Install the plugin /plugin install modern-web-guidance@googlechrome #3. Reload plugins /reload-plugins </code></pre> After installation, verify that .claude/skills/ exists in your project root and contains the skill file. That's where Claude Code reads skills from. Cursor: Modern Web Guidance is listed in the Skill Marketplace. <code>Search for modern-web-guidance and click Install, no CLI step required.</code> GitHub Copilot CLI: <pre><code class="language-shell"># 1. Add the marketplace /plugin marketplace add GoogleChrome/modern-web-guidance # 2. Install the plugin /plugin install modern-web-guidance@googlechrome </code></pre> Vercel Agent Skills: <pre><code class="language-shell">npx skills add GoogleChrome/modern-web-guidance </code></pre> Google Antigravity: One-click install available directly inside the app. <h2 id="heading-after-installing-modern-web-guidance-what-actually-changes">After Installing Modern Web Guidance: What Actually Changes</h2> <a href="#heading-why-do-ai-agents-default-to-legacy-patterns">Earlier</a>, we saw the outputs for the prompts on both the Tooltip and Toast Notification components when Modern Web Guidance was not installed. Run the same prompts with Modern Web Guidance installed and the agent reaches for entirely different tools. <h3 id="heading-after-tooltip-component">After: Tooltip Component</h3> With Modern Web Guidance, the same tooltip prompt produces no JavaScript at all. Instead, the agent reaches for two APIs working together: <code>popover="hint"</code> for native hover/focus-triggered visibility, and <code>interestfor</code> (the Interest Invokers API) to wire the trigger to its target declaratively in HTML. <pre><code class="language-html"> <div class="tooltip-wrapper"> <button id="btn-deploy" class="btn-trigger" interestfor="tooltip-deploy" > Deploy App </button> <div popover="hint" id="tooltip-deploy" class="tooltip-content"> Instantly push code changes live </div> </div> </code></pre> <pre><code class="language-css">/* Anchor positioning wires layout to the trigger */ #btn-deploy { anchor-name: --tooltip-deploy; } #tooltip-deploy { position-anchor: --tooltip-deploy; } .tooltip-content[popover] { position: absolute; bottom: anchor(top); left: anchor(center); transform: translateX(-50%) translateY(8px); opacity: 0; transition: opacity 0.2s ease, display 0.2s allow-discrete, overlay 0.2s allow-discrete; } .tooltip-content[popover]:popover-open { opacity: 1; transform: translateX(-50%) translateY(-12px); } @starting-style { .tooltip-content[popover]:popover-open { opacity: 0; transform: translateX(-50%) translateY(8px); } } </code></pre> The <code>js-hidden</code> class is gone. The <code>dismissAllTooltips()</code> function is gone. The <code>touchstart</code> handler is gone. The click-outside detection is gone. <code>popover="hint"</code> provides light-dismiss behavior natively, the browser handles hover intent, focus management, Escape-to-dismiss, and touch semantics without a line of JavaScript. <code>@starting-style</code> defines the entry animation state, and <code>allow-discrete</code> handles the exit, so both directions of the transition are owned entirely by CSS. Browser compatibility note: The Interest Invokers API (<code>interestfor</code>) is currently available in Chrome with a flag and has a polyfill at <code>unpkg.com/interestfor</code>. CSS Anchor Positioning is Baseline 2025. The agent also included polyfill loading in the output. Check <a href="https://caniuse.com/css-anchor-positioning">caniuse.com/css-anchor-positioning</a> and assess against your browser support requirements before shipping. One thing worth knowing: of the two APIs here, CSS Anchor Positioning is already shipping in stable browsers, while <code>interestfor</code> is the more experimental one. The polyfill covers it, but think of it as a preview of where the platform is heading rather than something you would ship to production today without testing. <h3 id="heading-after-toast-notification-with-exit-animation">After: Toast Notification with Exit Animation</h3> The same toast prompt with Modern Web Guidance produces a <code>popover="manual"</code> element instead of a class-toggled <code><div></code>. The browser's Top Layer handles rendering and stacking context natively. <pre><code class="language-javascript">// ✅ After MWG — the browser handles show/hide; JS handles auto-dismiss timing only const createToast = (type) => { const toast = document.createElement('div'); toast.setAttribute('popover', 'manual'); toast.className = `toast toast-${type}`; toast.innerHTML = ` <div class="toast-icon">...</div> <div class="toast-content">...</div> <button popovertarget="${toastId}" popovertargetaction="hide" class="toast-close" aria-label="Dismiss notification" >×</button> `; container.appendChild(toast); toast.showPopover(); // triggers @starting-style entry animation natively // Auto-dismiss const autoDismissTimer = setTimeout(() => { if (toast.matches(':popover-open')) toast.hidePopover(); }, 4000); // Remove from DOM after exit transition completes toast.addEventListener('beforetoggle', (event) => { if (event.newState === 'closed') { clearTimeout(autoDismissTimer); toast.addEventListener('transitionend', () => toast.remove(), { once: true }); setTimeout(() => { if (toast.parentNode) toast.remove(); }, 500); // fallback } }); }; </code></pre> <pre><code class="language-css">/* ✅ CSS owns both entry and exit animation */ .toast[popover] { opacity: 0; transform: translateX(60px) scale(0.95); transition: opacity 0.3s ease, transform 0.3s ease, display 0.3s allow-discrete, overlay 0.3s allow-discrete; } .toast[popover]:popover-open { opacity: 1; transform: translateX(0) scale(1); } @starting-style { .toast[popover]:popover-open { opacity: 0; transform: translateX(60px) scale(0.95); } } </code></pre> The manual close button now uses <code>popovertarget</code> and <code>popovertargetaction="hide"</code>, a declarative HTML binding that requires no click handler. <code>showPopover()</code> triggers the <code>@starting-style</code> entry animation natively. <code>hidePopover()</code> triggers the CSS exit transition via <code>allow-discrete</code>. JavaScript is now responsible for only two things: scheduling the auto-dismiss timeout and removing the element from the DOM after the exit transition completes. The animation coordination that previously required <code>transitionend</code> listeners, CSS class toggling, and synchronized timing is gone, as the browser owns it. <h2 id="heading-what-modern-web-guidance-does-not-handle-for-you">What Modern Web Guidance Does Not Handle for You</h2> Modern Web Guidance shifts what the agent writes on a first attempt. It doesn't eliminate the need for code review, and in practice two friction points come up consistently. <h3 id="heading-1-the-bleeding-edge-cliff">1. The Bleeding-edge Cliff</h3> Modern Web Guidance defaults to the newest Baseline features. <code>@starting-style</code>, <code>transition-behavior: allow-discrete</code>, CSS Anchor Positioning, and the Interest Invokers API are all correct, but some are new enough that they require polyfills for production use today. The agent will include those polyfill imports in its output. You still need to verify the features used against your actual browser support requirements. A junior developer reading <code>interestfor</code> or <code>position-anchor</code> for the first time will need to look these up, because Modern Web Guidance assumes you want the most modern correct answer, not the most familiar one. <h3 id="heading-2-the-css-encapsulation-trade-off">2. The CSS Encapsulation Trade-off</h3> When Modern Web Guidance guides the agent toward moving inline styles or <code>dangerouslySetInnerHTML</code> keyframes into a global stylesheet, which it does for security and hydration reasons, it breaks component-level encapsulation. Delete the component later and you'll have orphaned CSS in your global file. The call is architecturally correct, but you still need to namespace those classes and track the dependency manually. The 37-point improvement in best-practice adherence is real, but Modern Web Guidance is better understood as raising the default ceiling and not removing the need for human judgment. Think of it as giving your agent the habits of a developer who stays updated by actually reading current web docs. <h2 id="heading-conclusion">Conclusion</h2> The problem was never that AI coding agents were bad at web development. The problem is that they were working from an outdated picture of the platform, one shaped by training data that reflects the early 2020s web more than the browser capabilities available today. Modern Web Guidance updates that picture. The tooltip before/after alone tells the whole story: the agent went from a <code>js-hidden</code> state machine with touch handlers and click-outside detection to two HTML attributes and a block of CSS. The JavaScript interaction layer didn't get refactored, it became unnecessary. The code your agent writes is only as current as what it was trained on. Modern Web Guidance closes that gap. I ran this exact experiment on my own project. You can read the full case study with raw diffs at <a href="https://www.ophyboamah.com/blog/i-installed-modern-web-guidance-in-my-projects-heres-what-actually-changed">ophyboamah.com/blog</a>. Here are some helpful resources: <ul> <li><a href="https://developer.chrome.com/docs/modern-web-guidance">Modern Web Guidance</a> </li> <li><a href="https://www.youtube.com/watch?v=bo3i0FzDUYo">Modern Web Guidance video - Chrome for Developers</a> </li> <li><a href="https://github.com/GoogleChrome/modern-web-guidance">Modern Web Guidance open-source</a> (open to contributions) </li> </ul> </article> <article> <h1> How to Build a Browser-Based PDF Reverse Tool Using JavaScript </h1> Bhavin Sheth — Wed, 24 Jun 2026 20:37:18 +0000 PDF files are often created by combining scans, exporting documents from different systems, or processing large batches of pages. In many cases, the final PDF ends up with pages arranged in the wrong order. A PDF Reverse Tool solves this problem by flipping the page sequence automatically. Instead of manually rearranging pages one by one, users can reverse an entire document in seconds. In this tutorial, you'll learn how to build a browser-based PDF Reverse Tool using JavaScript and PDF-lib. The tool allows users to upload PDFs, preview pages, choose different reverse modes, generate a reversed document, and download the updated PDF directly from the browser. You can try the live tool here: Reverse PDF Tool: <a href="https://allinonetools.net/reverse-pdf/">https://allinonetools.net/reverse-pdf/</a> <h2 id="heading-table-of-contents">Table of Contents</h2> <ul> <li><a href="#heading-why-reversing-pdf-pages-is-useful">Why Reversing PDF Pages Is Useful</a> </li> <li><a href="#heading-how-pdf-page-reversal-works">How PDF Page Reversal Works</a> </li> <li><a href="#heading-project-setup">Project Setup</a> </li> <li><a href="#heading-what-library-are-we-using">What Library Are We Using?</a> </li> <li><a href="#heading-creating-the-upload-interface">Creating the Upload Interface</a> </li> <li><a href="#heading-previewing-uploaded-pdf-pages">Previewing Uploaded PDF Pages</a> </li> <li><a href="#heading-configuring-reverse-options">Configuring Reverse Options</a> </li> <li><a href="#heading-applying-the-reverse-operation">Applying the Reverse Operation</a> </li> <li><a href="#heading-generating-the-reversed-pdf">Generating the Reversed PDF</a> </li> <li><a href="#heading-why-pdf-reversal-is-useful-in-real-world-documents">Why PDF Reversal Is Useful in Real-World Documents</a> </li> <li><a href="#heading-demo-how-the-reverse-pdf-tool-works">Demo: How the Reverse PDF Tool Works</a> </li> <li><a href="#heading-important-notes-from-real-world-use">Important Notes from Real-World Use</a> </li> <li><a href="#heading-common-mistakes-to-avoid">Common Mistakes to Avoid</a> </li> <li><a href="#heading-conclusion">Conclusion</a> </li> </ul> <h2 id="heading-why-reversing-pdf-pages-is-useful">Why Reversing PDF Pages Is Useful</h2> PDF page reversal changes the order of pages inside a document. For example, a 10-page PDF normally follows this sequence: Page 1 → Page 2 → Page 3 → Page 4, and so on. After reversal, the order becomes Page 10 → Page 9 → Page 8 → Page 7, and on down. This process is useful when scanned documents are imported in the wrong sequence, when merged files need to be reordered, or when printing workflows require reverse page order. Instead of rearranging pages manually, users can reverse the entire document instantly. <h2 id="heading-how-pdf-page-reversal-works">How PDF Page Reversal Works</h2> A PDF Reverse Tool reads the uploaded PDF file, extracts its pages, rearranges the page order according to the selected reverse mode, and creates a new downloadable PDF. The browser loads the document, processes page indexes, copies pages into a new PDF document, and exports the updated file. Everything happens directly inside the browser. No files are uploaded to external servers, helping maintain privacy and improving processing speed. <h2 id="heading-project-setup">Project Setup</h2> Create a simple project structure: <pre><code class="language-text">pdf-reverse-tool/ │ ├── index.html ├── style.css ├── app.js │ └── libs/ └── pdf-lib.min.js </code></pre> Load PDF-lib: <pre><code class="language-html"><script src="libs/pdf-lib.min.js"></script> <script src="app.js"></script> </code></pre> <h2 id="heading-what-library-are-we-using">What Library Are We Using?</h2> This project uses PDF-lib. PDF-lib is a powerful JavaScript library that allows developers to create, modify, merge, split, organize, and export PDF documents directly inside the browser. For a page reversal tool, PDF-lib provides everything needed to read page indexes, copy pages, rearrange document structure, and generate updated PDFs. Example: <pre><code class="language-javascript">const pdfDoc = await PDFLib.PDFDocument.load(pdfBytes); const totalPages = pdfDoc.getPageCount(); console.log(totalPages); </code></pre> <h2 id="heading-creating-the-upload-interface">Creating the Upload Interface</h2> The first step is allowing users to upload a PDF document. A drag-and-drop upload area provides a simple and user-friendly experience while supporting traditional file selection. Example HTML: <pre><code class="language-html"><input type="file" id="pdfFile" accept=".pdf" /> </code></pre> Example JavaScript: <pre><code class="language-javascript">document .getElementById("pdfFile") .addEventListener("change", loadPDF); </code></pre> <h2 id="heading-previewing-uploaded-pdf-pages">Previewing Uploaded PDF Pages</h2> After a PDF is uploaded, users should be able to preview document pages before performing any operations. Page previews help users verify that the correct file was selected and make it easier to understand how the reversal process will affect the document. The preview section displays page thumbnails and allows users to navigate between pages before processing. Example: <pre><code class="language-javascript">const totalPages = pdfDoc.getPageCount(); for(let i = 0; i < totalPages; i++) { console.log(`Rendering page ${i + 1}`); } </code></pre> <h2 id="heading-configuring-reverse-options">Configuring Reverse Options</h2> The Reverse PDF Tool supports multiple reversal modes. Users can reverse an entire PDF document or reverse only a specific range of pages. For example, a user may want to reverse pages 10 through 20 while leaving the rest of the document unchanged. The tool also includes additional document-editing features such as rotating pages, adding blank pages, and importing another PDF before generating the final output. This flexibility makes the tool useful for both simple and advanced document workflows. Example configuration: <pre><code class="language-javascript">const reverseMode = "full"; const startPage = 5; const endPage = 15; </code></pre> <h2 id="heading-applying-the-reverse-operation">Applying the Reverse Operation</h2> Once the user selects the desired reverse mode, the tool generates a new page order. For a full document reversal, the last page becomes the first page and the first page becomes the last page. Example: <pre><code class="language-javascript">const reversedIndices = []; for(let i = totalPages - 1; i >= 0; i--) { reversedIndices.push(i); } </code></pre> The generated page order is then used when creating the final PDF. <h2 id="heading-generating-the-reversed-pdf">Generating the Reversed PDF</h2> PDF-lib allows pages to be copied into a new PDF document in any order. The reversal process creates a new PDF and inserts pages according to the generated sequence. Example: <pre><code class="language-javascript">const reversedIndices = []; for (let i = totalPages - 1; i >= 0; i--) { reversedIndices.push(i); } const copiedPages = await pdfDoc.copyPages( sourcePdf, reversedIndices ); copiedPages.forEach(page => { pdfDoc.addPage(page); }); </code></pre> Once processing is complete, the updated PDF is exported directly inside the browser. <h2 id="heading-why-pdf-reversal-is-useful-in-real-world-documents">Why PDF Reversal Is Useful in Real-World Documents</h2> Many documents are accidentally created in reverse order during scanning, merging, exporting, or printing workflows. A common example occurs when users scan large stacks of paper using automatic document feeders. Depending on how pages are loaded into the scanner, the resulting PDF may place the final page first and the first page last. Educational institutions frequently encounter this issue when scanning answer sheets, student records, assignments, admission documents, and examination papers. Businesses often receive contracts, invoices, purchase orders, reports, and legal documents that arrive in reverse sequence after scanning. A PDF reversal tool restores the intended reading order instantly. The feature is particularly useful for e-commerce businesses. For example, a seller may receive hundreds of shipping labels, invoices, packing slips, or courier documents from marketplaces such as Flipkart, Amazon, Meesho, or other platforms. Sometimes these documents are generated in reverse order compared to the packing workflow. Instead of manually rearranging pages, the seller can reverse the entire PDF and immediately print documents in the correct sequence. This saves significant time when processing large batches of orders. Accounting teams, warehouse staff, administrative departments, legal offices, publishers, and document management teams regularly use page reversal to streamline document preparation. The result is a cleaner workflow, reduced manual effort, and a document that is easier to read, print, archive, and distribute. <h2 id="heading-demo-how-the-reverse-pdf-tool-works">Demo: How the Reverse PDF Tool Works</h2> <h3 id="heading-step-1-upload-your-pdf-file">Step 1: Upload Your PDF File</h3> Users start by uploading a PDF document using either the drag-and-drop area or the file selection button. Once the file is selected, the browser reads the PDF locally and prepares it for processing. No files are uploaded to external servers, helping maintain privacy and security. The tool automatically loads the document structure and extracts page information required for preview generation and page reversal. <h3 id="heading-step-2-preview-uploaded-pages">Step 2: Preview Uploaded Pages</h3> After the PDF is loaded, the tool generates page previews directly inside the browser. Users can browse through the document pages before making any changes. This helps verify that the correct file has been uploaded and allows users to understand the current page sequence. The preview section also provides page navigation controls so users can move between pages and inspect the document before processing. <h3 id="heading-step-3-select-reverse-mode">Step 3: Select Reverse Mode</h3> Next, users choose how the page reversal should be applied. The tool supports two reversal modes. The first option reverses the entire document, changing the page order from first-to-last into last-to-first. The second option allows users to specify a page range and reverse only that section while keeping the rest of the document unchanged. Additional document editing options such as rotating pages, adding blank pages, importing another PDF, and resetting the document are also available before processing. <h3 id="heading-step-4-review-pages-before-processing">Step 4: Review Pages Before Processing</h3> Before generating the final PDF, users can review all page thumbnails and verify the selected reversal settings. This step is especially useful when working with large reports, scanned documents, contracts, books, manuals, invoices, and merged PDFs where page order is important. Taking a few moments to verify the document can prevent mistakes and reduce the need for reprocessing later. <h3 id="heading-step-5-reverse-the-document">Step 5: Reverse the Document</h3> After confirming the settings, users click the Reverse PDF button. The browser processes the selected pages and generates a new page sequence based on the chosen reversal mode. Since everything happens locally inside the browser, processing is usually very fast and no document data leaves the user's device. <h3 id="heading-step-6-preview-the-reversed-pdf">Step 6: Preview the Reversed PDF</h3> Once processing is complete, the tool displays the newly generated PDF. Users can browse through the updated document using the page navigation controls and verify that the page order has been reversed correctly. This preview stage provides a final opportunity to inspect the output before downloading. <h3 id="heading-step-7-download-the-final-pdf">Step 7: Download the Final PDF</h3> After confirming the results, users can download the updated document. The final output section displays useful file information including the generated filename, total number of pages, and file size as well as file rename option before download. This information helps users quickly verify that the output matches expectations before saving the file. The document can then be downloaded and used immediately for printing, sharing, archiving, business workflows, educational records, legal documents, or other PDF-related tasks. <h2 id="heading-important-notes-from-real-world-use">Important Notes from Real-World Use</h2> Large PDF files may require additional processing time, especially when reversing documents containing hundreds or thousands of pages. When processing large PDFs, it's a good practice to validate the uploaded file before loading it into memory. Example: <pre><code class="language-javascript">if (file.size > 50 * 1024 * 1024) { alert("Large PDF detected. Processing may take longer."); } </code></pre> When working with very large documents, developers should avoid unnecessary page rendering operations to reduce memory usage and improve performance. It's also recommended to verify the page count before starting the reversal process. Example: <pre><code class="language-javascript">const totalPages = pdfDoc.getPageCount(); console.log(`Pages: ${totalPages}`); </code></pre> Previewing the final output before download helps users catch mistakes early and confirm that the page order has been reversed correctly. Since processing happens entirely inside the browser, documents never leave the user's device, providing better privacy and security for sensitive files. This approach is especially useful when working with business reports, legal documents, invoices, contracts, educational records, and confidential PDFs that shouldn't be uploaded to third-party servers. <h2 id="heading-common-mistakes-to-avoid">Common Mistakes to Avoid</h2> One common mistake is reversing a document without first checking the existing page order. Many users assume the pages are arranged incorrectly and reverse the entire document, only to discover that the original file was already in the correct sequence. Before processing, it's a good idea to verify the first and last pages. Example: <pre><code class="language-javascript">const totalPages = pdfDoc.getPageCount(); console.log(`First Page: 1`); console.log(`Last Page: ${totalPages}`); </code></pre> Another common mistake is reversing an entire PDF when only a specific section needs to be reordered. Large reports, books, manuals, and scanned documents sometimes require only a subset of pages to be reversed. Always confirm whether a full-document reversal or a custom range reversal is required. Example: <pre><code class="language-javascript">const startPage = 10; const endPage = 25; console.log(`Reverse pages ${startPage} to ${endPage}`); </code></pre> Users also frequently assume scanned pages are already arranged correctly. But automatic document feeders and batch scanners can sometimes create PDFs with pages in unexpected sequences. Previewing uploaded pages before processing helps identify these issues early. Another mistake is skipping the final preview after generating the reversed PDF. A quick review allows users to confirm that page order, page count, and document structure are correct before downloading. Example: <pre><code class="language-javascript">const finalPages = reversedPdf.getPageCount(); console.log(`Output Pages: ${finalPages}`); </code></pre> Taking a few seconds to verify the output can prevent unnecessary reprocessing, save time, and ensure the final PDF is ready for sharing, printing, archiving, or business use. <h2 id="heading-conclusion">Conclusion</h2> In this tutorial, you built a browser-based PDF Reverse Tool using JavaScript. You learned how to upload PDF files, preview document pages, configure reverse modes, generate reversed page orders, and create downloadable PDF documents directly inside the browser. More importantly, you saw how modern browsers can perform document organization tasks locally without relying on backend servers. This approach keeps document processing fast, private, and easy to use. You can try the live implementation here: <a href="https://allinonetools.net/reverse-pdf/">Reverse PDF Tool</a> Once you understand this workflow, you can extend it further with features such as PDF splitting, merging, page rotation, page numbering, metadata editing, watermarking, document encryption, and advanced PDF organization tools. </article> <article> <h1> How to Build an Animated Badge Component with shadcn/ui </h1> Vaibhav Gupta — Wed, 24 Jun 2026 17:00:48 +0000 Badges are everywhere in modern web apps. You see them on notification counters, status labels, and feature tags. Most of them are static, though. They sit there doing nothing, blending into the page. But a well-animated badge can tell the user something happened without them having to read a single word. In this tutorial, you'll build an animated “success” badge using shadcn/ui, Tailwind CSS, and Framer Motion. The badge will have a glowing top light, an animated check icon that bounces into view, and letters that drop in one at a time with a stagger effect. The component comes from the <a href="https://shadcnspace.com/components/badge">Shadcn Space badge collection</a> and uses the Base UI primitive version of Badge. You'll install it with a single CLI command, then walk through every piece of code. By the end, you'll build an animated "Success" badge by: <ol> <li>Installing the <code>badge-07</code> component from Shadcn Space using the Shadcn CLI </li> <li>Using <code>motion.create()</code> to wrap the shadcn/ui <code>Badge</code> into an animatable component </li> <li>Adding layered radial-gradient glow effects as absolutely positioned spans </li> <li>Animating the check icon with a scale and rotate entrance </li> <li>Animating each letter of the label individually using staggered <code>variants</code> </li> </ol> <h2 id="heading-table-of-contents">Table of Contents</h2> <ul> <li><a href="#heading-prerequisites">Prerequisites</a> </li> <li><a href="#heading-what-youll-build">What You'll Build</a> </li> <li><a href="#heading-how-to-install-the-component">How to Install the Component</a> </li> <li><a href="#heading-component-structure">Component Structure</a> </li> <li><a href="#heading-step-1-set-up-the-imports">Step 1: Set Up the Imports</a> </li> <li><a href="#heading-step-2-define-letter-animation-variants">Step 2: Define Letter Animation Variants</a> </li> <li><a href="#heading-step-3-wrap-the-badge-with-motion">Step 3: Wrap the Badge with Motion</a> </li> <li><a href="#heading-step-4-build-the-glow-layers">Step 4: Build the Glow Layers</a> </li> <li><a href="#heading-step-5-animate-the-icon">Step 5: Animate the Icon</a> </li> <li><a href="#heading-step-6-animate-each-letter">Step 6: Animate Each Letter</a> </li> <li><a href="#heading-how-to-use-it-in-your-app">How to Use It in Your App</a> </li> <li><a href="#heading-how-to-customize-the-component">How to Customize the Component</a> </li> <li><a href="#heading-live-preview">Live Preview</a> </li> <li><a href="#heading-key-concepts-recap">Key Concepts Recap</a> </li> <li><a href="#heading-conclusion">Conclusion</a> </li> <li><a href="#heading-resources">Resources</a> </li> </ul> <h2 id="heading-prerequisites">Prerequisites</h2> You'll need: <ul> <li>A Next.js project with shadcn/ui initialized </li> <li>Tailwind CSS set up </li> <li><code>motion</code> installed: <code>npm install motion</code> </li> <li><code>lucide-react</code> installed: <code>npm install lucide-react</code> </li> <li>Basic TypeScript and React knowledge </li> </ul> <h2 id="heading-what-youll-build">What You'll Build</h2> In this tutorial, we'll build a self-contained animated badge with three moving parts: <pre><code class="language-plaintext">├── MotionBadge (outline, rounded-full, teal border) │ ├── Glow layers → 3 radial gradient spans above the top border │ ├── CheckCircle → scale + rotate entrance, easeOutBack │ └── Letter spans → staggered drop-in, easeOutCubic </code></pre> After installation, the component file lands here: <pre><code class="language-plaintext">components/ └── shadcn-space/ └── badge/ └── badge-07.tsx </code></pre> <h2 id="heading-how-to-install-the-component">How to Install the Component</h2> <a href="https://shadcnspace.com/">Shadcn UI</a> provides a registry of production-ready components. You pull them into your project with the Shadcn CLI, just like you'd add any standard shadcn/ui component. Before running any command, check the <a href="https://shadcnspace.com/docs/getting-started/how-to-use-shadcn-cli">Getting Started guide</a> or the <a href="https://shadcnspace.com/cli">CLI page</a> for setup details. You can also follow along with this video walkthrough: <div class="embed-wrapper"></div> Run the command for your package manager: pnpm <pre><code class="language-javascript">pnpm dlx shadcn@latest add @shadcn-space/badge-07 </code></pre> npm <pre><code class="language-javascript">npx shadcn@latest add @shadcn-space/badge-07 </code></pre> Yarn <pre><code class="language-javascript">yarn dlx shadcn@latest add @shadcn-space/badge-07 </code></pre> Bun <pre><code class="language-javascript">bunx --bun shadcn@latest add @shadcn-space/badge-07 </code></pre> Note: <code>badge-07</code> uses the Base UI primitive version of Badge. Both Radix and Base UI versions are available in the registry. This tutorial covers the Base UI version. <h2 id="heading-component-structure">Component Structure</h2> Here's the complete component. Read through it once, then each step below breaks down a specific part. <pre><code class="language-javascript">'use client' import { motion, type Variants } from "motion/react"; import { CheckCircle } from "lucide-react"; import { Badge } from "@/components/ui/badge"; import { cn } from "@/lib/utils"; const LETTER_VARIANTS: Variants = { hidden: { y: -14, opacity: 0 }, visible: (i: number) => ({ y: 0, opacity: 1, transition: { delay: i * 0.038, duration: 0.35, ease: [0.215, 0.61, 0.355, 1], }, }), }; const MotionBadge = motion.create(Badge); const SuccessBadgeDemo = () => { const label = "Success"; return ( <MotionBadge variant="outline" className={cn( "relative h-auto cursor-default overflow-visible rounded-full", "gap-2 px-3 py-2", "bg-background backdrop-blur-md", "text-foreground text-sm font-medium leading-none", "border-teal-400/25", )} > {/* Top glow */} <motion.span aria-hidden animate={{ opacity: 0.55 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute -top-2 left-[10%] right-[10%] h-4 blur bg-[radial-gradient(ellipse_80%_100%_at_50%_100%,rgba(45,212,191,0.95)_0%,transparent_70%)]" /> <motion.span aria-hidden animate={{ opacity: 0.75 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute -top-1 left-[22%] right-[22%] h-2 blur-sm bg-[radial-gradient(ellipse_70%_100%_at_50%_100%,rgba(45,212,191,0.85)_0%,transparent_70%)]" /> <motion.span aria-hidden animate={{ opacity: 0.9 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute top-0 left-[28%] right-[28%] h-px bg-[radial-gradient(ellipse_40%_50%_at_50%_50%,rgba(45,212,191,0.95)_0%,transparent_100%)]" /> {/* Icon */} <motion.span initial={{ scale: 0.35, opacity: 0, rotate: -25 }} animate={{ scale: 1, opacity: 1, rotate: 0 }} transition={{ duration: 0.32, ease: [0.175, 0.885, 0.32, 1.275] }} className="flex h-4 w-4 shrink-0 items-center justify-center" > <CheckCircle size={16} strokeWidth={2} className="text-teal-400" /> </motion.span> {/* Animated label */} {label.split("").map((char, i) => ( <motion.span key={i} custom={i} variants={LETTER_VARIANTS} initial="hidden" animate="visible" className="inline-block whitespace-pre" > {char} </motion.span> ))} </MotionBadge> ); }; export default SuccessBadgeDemo; </code></pre> Now let's break it down piece by piece. <h2 id="heading-step-1-set-up-the-imports">Step 1: Set Up the Imports</h2> <pre><code class="language-javascript">'use client' import { motion, type Variants } from "motion/react"; import { CheckCircle } from "lucide-react"; import { Badge } from "@/components/ui/badge"; import { cn } from "@/lib/utils"; </code></pre> <code>'use client'</code> marks this as a Client Component in Next.js App Router. Motion animations run in the browser, not on the server, so this directive is required. <code>motion/react</code> is the import path for Motion v11 and above. If your project uses an older version, the import is <code>framer-motion</code>. The <code>Variants</code> type is a TypeScript helper for typing named animation state objects. <code>cn()</code> is the class name utility that ships with every shadcn/ui project. It merges Tailwind classes and handles conditional logic cleanly. <h2 id="heading-step-2-define-letter-animation-variants">Step 2: Define Letter Animation Variants</h2> <pre><code class="language-javascript">const LETTER_VARIANTS: Variants = { hidden: { y: -14, opacity: 0 }, visible: (i: number) => ({ y: 0, opacity: 1, transition: { delay: i * 0.038, duration: 0.35, ease: [0.215, 0.61, 0.355, 1], }, }), }; </code></pre> Each letter starts 14px above its final position and is fully transparent. When the component mounts, it moves to <code>y: 0</code> at full opacity. The <code>delay: i * 0.038</code> formula is the stagger. Letter 0 has no delay, letter 1 waits 38ms, letter 2 waits 76ms, and so on. This makes the letters appear to cascade in from left to right. The <code>ease</code> value <code>[0.215, 0.61, 0.355, 1]</code> is <code>easeOutCubic</code>. It starts fast and decelerates at the end, giving each letter a natural landing rather than a hard stop. The <code>visible</code> function accepts a <code>custom</code> value. When you pass <code>custom={i}</code> on the <code>motion.span</code>, Motion calls this function with that index. Each letter calculates its own delay independently. Accessibility tip: To respect users with reduced motion preferences, import <code>useReducedMotion</code> from <code>motion/react</code> and skip the stagger when it returns <code>true</code>. <h2 id="heading-step-3-wrap-the-badge-with-motion">Step 3: Wrap the Badge with Motion</h2> <pre><code class="language-javascript">const MotionBadge = motion.create(Badge); </code></pre> The <code>Badge</code> Component from shadcn/ui is a standard React component. You can't apply Motion props like <code>animate</code> or <code>initial</code> to it directly. <code>motion.create()</code> wraps any React component and returns a new version that accepts all Motion animation props. The result, <code>MotionBadge</code>, behaves exactly like <code>Badge</code> But it's now fully animatable. Use this pattern any time you want to animate a custom or third-party library component with Motion. <h2 id="heading-step-4-build-the-glow-layers">Step 4: Build the Glow Layers</h2> <pre><code class="language-javascript"><motion.span aria-hidden animate={{ opacity: 0.55 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute -top-2 left-[10%] right-[10%] h-4 blur bg-[radial-gradient(ellipse_80%_100%_at_50%_100%,rgba(45,212,191,0.95)_0%,transparent_70%)]" /> <motion.span aria-hidden animate={{ opacity: 0.75 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute -top-1 left-[22%] right-[22%] h-2 blur-sm bg-[radial-gradient(ellipse_70%_100%_at_50%_100%,rgba(45,212,191,0.85)_0%,transparent_70%)]" /> <motion.span aria-hidden animate={{ opacity: 0.9 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute top-0 left-[28%] right-[28%] h-px bg-[radial-gradient(ellipse_40%_50%_at_50%_50%,rgba(45,212,191,0.95)_0%,transparent_100%)]" /> </code></pre> Three spans stack on top of each other above the badge border. Each is narrower and more opaque than the one behind it: <table> <thead> <tr> <th>Layer</th> <th>Position</th> <th>Width</th> <th>Blur</th> <th>Final Opacity</th> </tr> </thead> <tbody><tr> <td>Outer</td> <td><code>-top-2</code></td> <td>80%</td> <td><code>blur</code></td> <td>0.55</td> </tr> <tr> <td>Middle</td> <td><code>-top-1</code></td> <td>56%</td> <td><code>blur-sm</code></td> <td>0.75</td> </tr> <tr> <td>Inner line</td> <td><code>top-0</code></td> <td>44%</td> <td>none</td> <td>0.90</td> </tr> </tbody></table> The innermost layer is only 1px tall (<code>h-px</code>) with no blur. This gives the glow a crisp, bright edge right at the badge border. The two outer layers create the soft falloff around it. All three carry <code>aria-hidden</code> because they're purely decorative. Screen readers skip them. The <code>overflow-visible</code> class on <code>MotionBadge</code> is what allows these spans to render outside the component's boundary without clipping. <h2 id="heading-step-5-animate-the-icon">Step 5: Animate the Icon</h2> <pre><code class="language-javascript"><motion.span initial={{ scale: 0.35, opacity: 0, rotate: -25 }} animate={{ scale: 1, opacity: 1, rotate: 0 }} transition={{ duration: 0.32, ease: [0.175, 0.885, 0.32, 1.275] }} className="flex h-4 w-4 shrink-0 items-center justify-center" > <CheckCircle size={16} strokeWidth={2} className="text-teal-400" /> </motion.span> </code></pre> The icon starts at 35% scale, invisible, and rotated 25 degrees counter-clockwise. It animates to full size and zero rotation on mount. The <code>ease</code> value <code>[0.175, 0.885, 0.32, 1.275]</code> is <code>easeOutBack</code>. Unlike <code>easeOutCubic</code>, this curve overshoots its target slightly before snapping back. The icon appears to spring into place. It is a subtle effect, but it makes the icon feel physical. <code>shrink-0</code> on the wrapper prevents the icon from compressing inside the flex container. <h2 id="heading-step-6-animate-each-letter">Step 6: Animate Each Letter</h2> <pre><code class="language-javascript"> {label.split("").map((char, i) => ( <motion.span key={i} custom={i} variants={LETTER_VARIANTS} initial="hidden" animate="visible" className="inline-block whitespace-pre" > {char} </motion.span> ))} </code></pre> <code>label.split("")</code> turns <code>"Success"</code> into <code>["S", "u", "c", "c", "e", "s", "s"]</code>. Each character gets its own <code>motion.span</code>. <code>variants={LETTER_VARIANTS}</code> connects each span to the animation states from Step 2. <code>custom={i}</code> passes the character's index into the <code>visible</code> resolver so each letter knows its own delay. Two Tailwind classes matter here: <ul> <li><code>overflow-hidden</code> on the wrapper clips, each letter as it slides in from above. Without it, letters would be visible outside the badge before they land. </li> <li><code>inline-block</code> on each <code>motion.span</code> is required for <code>translateY</code> to work. CSS transforms do not apply to inline elements by default. </li> </ul> <h2 id="heading-how-to-use-it-in-your-app">How to Use It in Your App</h2> Import and render <code>SuccessBadgeDemo</code> anywhere in your project: <pre><code class="language-javascript">// app/page.tsx import SuccessBadgeDemo from "@/components/shadcn-space/badge/badge-07"; export default function Page() { return ( <div className="flex items-center justify-center min-h-screen"> <SuccessBadgeDemo /> </div> ); } </code></pre> The component is self-contained. It carries its own animation state, theme tokens, and glow layers. No props are required. <h2 id="heading-how-to-customize-the-component">How to Customize the Component</h2> You can change the label by replacing <code>"Success"</code> it with any string. The letter animation applies automatically since it splits whatever string you pass. To build a complete blue "Verified" variant, you just need to change three things: the border color class, the glow gradient color values, and the icon. Here's the full updated component: <pre><code class="language-javascript">'use client' import { motion, type Variants } from "motion/react"; import { ShieldCheck } from "lucide-react"; import { Badge } from "@/components/ui/badge"; import { cn } from "@/lib/utils"; const LETTER_VARIANTS: Variants = { hidden: { y: -14, opacity: 0 }, visible: (i: number) => ({ y: 0, opacity: 1, transition: { delay: i * 0.038, duration: 0.35, ease: [0.215, 0.61, 0.355, 1], }, }), }; const MotionBadge = motion.create(Badge); const VerifiedBadgeDemo = () => { const label = "Verified"; return ( <MotionBadge variant="outline" className={cn( "relative h-auto cursor-default overflow-visible rounded-full", "gap-2 px-3 py-2", "bg-background backdrop-blur-md", "text-foreground text-sm font-medium leading-none", "border-blue-400/25", )} > <motion.span aria-hidden animate={{ opacity: 0.55 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute -top-2 left-[10%] right-[10%] h-4 blur bg-[radial-gradient(ellipse_80%_100%_at_50%_100%,rgba(96,165,250,0.95)_0%,transparent_70%)]" /> <motion.span aria-hidden animate={{ opacity: 0.75 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute -top-1 left-[22%] right-[22%] h-2 blur-sm bg-[radial-gradient(ellipse_70%_100%_at_50%_100%,rgba(96,165,250,0.85)_0%,transparent_70%)]" /> <motion.span aria-hidden animate={{ opacity: 0.9 }} transition={{ duration: 0.45 }} className="pointer-events-none absolute top-0 left-[28%] right-[28%] h-px bg-[radial-gradient(ellipse_40%_50%_at_50%_50%,rgba(96,165,250,0.95)_0%,transparent_100%)]" /> <motion.span initial={{ scale: 0.35, opacity: 0, rotate: -25 }} animate={{ scale: 1, opacity: 1, rotate: 0 }} transition={{ duration: 0.32, ease: [0.175, 0.885, 0.32, 1.275] }} className="flex h-4 w-4 shrink-0 items-center justify-center" > <ShieldCheck size={16} strokeWidth={2} className="text-blue-400" /> </motion.span> {label.split("").map((char, i) => ( <motion.span key={i} custom={i} variants={LETTER_VARIANTS} initial="hidden" animate="visible" className="inline-block whitespace-pre" > {char} </motion.span> ))} </MotionBadge> ); }; export default VerifiedBadgeDemo; </code></pre> The only changes from the original: <code>border-blue-400/25</code> on the badge, <code>rgba(96, 165, 250, ...)</code> in the glow gradients (<code>blue-400</code> in Tailwind), <code>ShieldCheck</code> for the icon, and <code>text-blue-400</code> on the icon class. To adjust stagger speed, just change the delay multiplier in <code>LETTER_VARIANTS</code>: <pre><code class="language-javascript">delay: i * 0.06, // slower stagger delay: i * 0.02, // faster stagger </code></pre> You can also explore the <a href="https://shadcnspace.com/blocks">Shadcn Blocks</a> collection to see how animated badges fit into full dashboard and card layouts. <hr> <h2 id="heading-live-preview">Live Preview</h2> <h2 id="heading-key-concepts-recap">Key Concepts Recap</h2> <table> <thead> <tr> <th>Concept</th> <th>What It Does</th> </tr> </thead> <tbody><tr> <td><code>motion.create(Component)</code></td> <td>Wraps any React component to accept Motion animation props</td> </tr> <tr> <td><code>Variants</code></td> <td>Named animation states (<code>hidden</code>, <code>visible</code>) defined outside JSX for reuse</td> </tr> <tr> <td><code>custom={i}</code> + variant function</td> <td>Passes a per-element value into the variant resolver for dynamic transitions</td> </tr> <tr> <td><code>delay: i * 0.038</code></td> <td>Stagger formula: each element's delay grows by its index</td> </tr> <tr> <td><code>easeOutCubic</code> <code>[0.215, 0.61, 0.355, 1]</code></td> <td>Fast start, smooth deceleration. Letter drop-in.</td> </tr> <tr> <td><code>easeOutBack</code> <code>[0.175, 0.885, 0.32, 1.275]</code></td> <td>Overshoots slightly, snaps back. Icon pop.</td> </tr> <tr> <td>Three stacked radial gradients</td> <td>Wide + soft outer glow, narrow + sharp inner line</td> </tr> <tr> <td><code>overflow-visible</code> on the badge</td> <td>Allows glow spans to extend outside the component's own bounds</td> </tr> </tbody></table> <h2 id="heading-conclusion">Conclusion</h2> In this tutorial, you built a complete animated badge from scratch with a layered glow, bouncing icon, and staggered letter animation. Every part of it uses your existing Shadcn theme tokens, so it drops into any project without extra configuration. You can browse more <a href="https://shadcnspace.com/components">Shadcn Components</a> on Shadcn Space to apply the same animation patterns to other UI elements. If you work with external services and tooling in your stack, the <a href="https://shadcnspace.com/mcp">Shadcn MCP</a> integration is worth looking at as a next step. <h2 id="heading-resources">Resources</h2> <ul> <li><a href="https://shadcnspace.com/components/badge">Shadcn Space Badge Components</a>: with all badge variants, including Pending, Failed, and more </li> <li><a href="https://shadcnspace.com/docs/getting-started/how-to-use-shadcn-cli">Shadcn Space Getting Started Guide</a>: how to use the Shadcn CLI with third-party registries </li> <li><a href="https://motion.dev/">Motion Docs</a>: official documentation for <code>motion/react</code> </li> <li><a href="https://lucide.dev/">Lucide React</a>: icon library used in this tutorial </li> <li><a href="https://ui.shadcn.com/docs">Shadcn/ui Documentation</a> </li> <li><a href="https://youtu.be/n6dvjVxy02U?si=EXfClzSyI8D97VaI">YouTube: Shadcn Space CLI Walkthrough</a> </li> </ul> </article> <article> <h1> From LLMs to LangChain: Understanding How Modern AI Applications Actually Work </h1> Sudheesh Shetty — Tue, 23 Jun 2026 15:49:39 +0000 Typically, when we start experimenting with AI, many of us begin similarly. We try a single LLM call as the core of an app, like this: <pre><code class="language-plaintext">const response = await llm.chat("Explain Kubernetes"); </code></pre> For a little while it feels like the whole flow is: the user asks something, and the model returns an answer. That early success often creates a false impression that building AI is just about sending prompts and getting responses. That simplicity is seductive, but it doesn't hold up. Over time, users want the assistant to find answers in their documents and knowledge bases, call APIs, fetch live data, or trigger services or schedule meetings. Users also expect the agent to access internal systems and interact with ERPs, CRMs, or other tools holding critical business data. They'll want agents to combine multiple steps, as workflows often require chaining queries, computations, and side effects into reliable processes. This is where concepts like MCP (the Model Context Protocol) and tools like LangChain come in. Initially, they may seem like buzzwords, but they address different aspects of LLM production. After experimenting with AI tools, I found that these concepts help solve different problems related to interfaces, orchestration, and system integration. This article is a practical guide to understanding how LLMs connect with tools, orchestrate workflows, and power real AI applications. <h3 id="heading-heres-what-well-cover">Here’s what we’ll cover:</h3> <ol> <li><a href="#heading-what-is-an-llm">What Is an LLM?</a> </li> <li><a href="#heading-why-llms-need-tools">Why LLMs Need Tools</a> </li> <li><a href="#heading-where-mcp-comes-in">Where MCP Comes In</a> </li> <li><a href="#heading-so-what-does-langchain-actually-do">So What Does LangChain Actually Do?</a> </li> <li><a href="#heading-putting-it-together">Putting It Together</a> </li> <li><a href="#heading-what-i-built-while-learning-this">What I Built While Learning This</a> </li> </ol> Throughout the article we'll discuss what LLMs are and how they work, what tool-calling looks like in practice, what MCP is and how it works, how LangChain fits into the whole process, and how to put all these tools together. To follow along, you'll need a basic understanding of Node.js, API operations, and basic JavaScript concepts. <h2 id="heading-what-is-an-llm">What Is an LLM?</h2> LLM stands for Large Language Model. It's a class of deep neural networks trained on massive amounts of text to model and generate human-like language. Popular examples you might have heard of include GPT, Claude, Gemini, and Llama. <h3 id="heading-how-to-call-an-llm-from-a-nodejs-application">How to Call an LLM From a Node.js Application</h3> Before writing code, let’s understand what it means to call an LLM from a Node.js application. Calling an LLM means sending input from your application to an AI provider’s API and receiving generated output in return. It's similar to calling any other external service. In most real-world applications, the model isn't hosted or trained by your application. Instead, providers such as OpenAI and Groq host and maintain the models, while your application communicates with them over HTTP APIs. In this example, we’ll build a minimal API using Node.js and Express. We’ll create a simple <code>POST /chat</code> endpoint that accepts a user message, sends it to the OpenAI API, receives the generated response, and returns it to the client. Here, our Node.js server acts as the bridge between the user and the LLM provider. For this example, create an API key from the <a href="https://console.groq.com/keys">Groq</a> console. Since it offers a free tier, it’s a simple way to experiment and understand the concepts. First, install the dependencies: <pre><code class="language-plaintext">npm install express </code></pre> <pre><code class="language-javascript">import express from "express"; const app = express(); app.use(express.json()); app.post("/chat", async (req, res) => { const { message } = req.body; const response = await fetch("https://api.groq.com/openai/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", Authorization: GROQ_API_KEY, }, body: JSON.stringify({ model: "llama-3.3-70b-versatile", messages: [{ role: "user", content: message }], }), }); const data = await response.json(); if (!response.ok) { return res.status(response.status).json({ error: data }); } const reply = data.choices[0].message.content; res.json({ reply }); }); const PORT = process.env.PORT || 8888; app.listen(PORT, () => { console.log(`Server running on http://localhost:${PORT}`); }); </code></pre> Start the server and make a request. Use Postman and do a POST request to <code>/chat</code> using the below body: <pre><code class="language-plaintext">POST /chat { "message": "Explain Kubernetes" } </code></pre> Example response: <pre><code class="language-plaintext">{ "reply": "Kubernetes is a container orchestration platform..." } </code></pre> The backend receives the message, forwards it to the model provider, receives generated text, and returns it to the client. LLMs are excellent at language-centric tasks: they understand phrasing and intent, generate coherent text, extract structured information from unstructured input, and perform basic reasoning over provided context. These capabilities make them powerful for things like summarization, drafting, and conversational QA. But there’s an important limitation: LLMs don't automatically know about and can't access your private or live data. They don’t have implicit access to your company database, internal APIs, or the current state of your systems unless you provide that information at runtime. Because of that limitation, you need secure mechanisms to connect models to live systems and data — which brings us to the idea of tools. <h2 id="heading-why-llms-need-tools">Why LLMs Need Tools</h2> Imagine asking: <blockquote> Check my order and raise support if delivery is delayed. </blockquote> The model alone can't inspect your order database or create a support ticket in your system. To do that, it must call external functions — for example, a <code>getOrderStatus(orderId)</code> API and a <code>createSupportTicket(orderId, issue)</code> action. Those callable functions are what we call tools: programmatic interfaces the AI can use to interact with systems and take concrete actions on behalf of users. A tool is simply a function that an AI model can call to interact with external systems or perform actions. For example, imagine we have a getOrderStatus(id) function that returns an order’s delivery status. To expose this to the LLM, we define a tools array. Each tool includes: <ul> <li>type – currently "function" </li> <li>function name – the function identifier </li> <li>function description – helps the LLM decide when to call the tool </li> <li>function parameters – a JSON Schema describing the arguments the tool expects </li> </ul> Here's an example: <pre><code class="language-typescript">function getOrderStatus(id) { const statuses = ["pending", "success", "cancelled"]; const status = statuses[Math.floor(Math.random() * statuses.length)]; return `Your order status is ${status}.`; } const tools = [ { type: "function", function: { name: "getOrderStatus", description: "Get the status of an order by its ID", parameters: { type: "object", properties: { id: { type: "string", description: "The order ID" }, }, required: ["id"], }, }, }, ]; </code></pre> The above tool format is for Grok. Different LLM providers may use different formats for defining tools, but the overall idea remains the same. When making the API call, we pass both the user messages and the list of available tools. <pre><code class="language-typescript">body: JSON.stringify({ model: "llama-3.3-70b-versatile", messages: [{ role: "user", content: message }], tools, }), </code></pre> After the API call, the LLM decides whether a tool is needed. If a tool call is requested, our application executes the corresponding function and sends the result back to the model. For this example, we'll only handle the <code>getOrderStatus</code> tool. We can check whether the model requested a tool call like this: <pre><code class="language-typescript">const toolCall = data.choices[0].message.tool_calls[0]; const { id } = JSON.parse(toolCall.function.arguments); const toolResult = getOrderStatus(id) </code></pre> and later we can pass the message context with tool result <pre><code class="language-typescript">body: JSON.stringify({ model: "llama-3.3-70b-versatile", messages: [ { role: "user", content: message }, assistantMessage, { role: "tool", tool_call_id: toolCall.id, content: toolResult }, ], tools, }), </code></pre> Finally, return the response: <pre><code class="language-typescript">return res.json({ reply: followUpData.choices[0].message.content }); </code></pre> Here's a diagram of the flow: LLM -> Tool Execution -> Tool Result -> Final Response" style="display:block;margin:0 auto" width="1774" height="887" loading="lazy"> The LLM decides whether a tool is needed and generates the required inputs, while your application executes the function. <h2 id="heading-where-mcp-comes-in">Where MCP Comes In</h2> Tools are simple. You define functions and tell the AI what it can use. For example, <code>getOrderStatus()</code> works well when all tools are built inside your application. But as applications grow, tools may come from many places, like Slack, GitHub, databases, internal systems, or third-party services. Each one may expose tools differently. This is where <a href="https://www.freecodecamp.org/news/how-does-an-mcp-work-under-the-hood/">MCP (Model Context Protocol) helps</a>. Think of MCP as a common language that lets AI systems connect to external tools in a consistent way. Tools define what the AI can do. MCP standardizes how the AI connects to and uses those tools. Now let’s extend the previous /chat API example so the LLM can use tools exposed through MCP. There are multiple ways to do this: <ul> <li>build and host your own MCP server and expose your application functions </li> <li>connect to existing third-party MCP servers such as Slack </li> </ul> For this tutorial, we'll keep things simple and use a remote MCP server approach because it's easier to understand. <pre><code class="language-plaintext">npm install express @modelcontextprotocol/sdk zod </code></pre> Now let’s create our own MCP server and expose the same <code>getOrderStatus</code> function as an MCP tool: <pre><code class="language-typescript">import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { createMcpExpressApp } from "@modelcontextprotocol/sdk/server/express.js"; import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js"; import { z } from "zod"; function getOrderStatus(id) { const statuses = ["pending", "success", "cancelled"]; const status = statuses[Math.floor(Math.random() * statuses.length)]; return `Your order status is ${status}.`; } function createOrderServer() { const server = new McpServer({ name: "order-server", version: "1.0.0" }); server.registerTool( "getOrderStatus", { description: "Get the status of an order by its ID", inputSchema: { id: z.string() }, }, async ({ id }) => ({ content: [{ type: "text", text: getOrderStatus(id) }], }) ); return server; } const app = createMcpExpressApp({ host: "0.0.0.0" }); app.post("/mcp", async (req, res) => { const server = createOrderServer(); const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined, }); res.on("close", () => { transport.close(); server.close(); }); await server.connect(transport); await transport.handleRequest(req, res, req.body); }); const PORT = process.env.PORT || 3001; app.listen(PORT, "0.0.0.0", () => { console.log(`Order MCP server running on http://0.0.0.0:${PORT}/mcp`); }); </code></pre> This is useful when you want to expose your own application functions through MCP. Typically, the MCP server runs separately and is accessed by MCP clients. Now any MCP client can connect to this server and discover the available tools automatically. The same idea applies to third-party MCP servers. For example, if a Slack MCP server is available, we can connect to it instead of writing Slack integration code ourselves. In that case, our application isn't directly calling Slack APIs. It connects to the Slack MCP server, which exposes Slack-related tools using the MCP standard. So the difference is: <ul> <li>For our own features, we can build our own MCP server </li> <li>For external systems, we can use existing MCP servers when available </li> </ul> Now we can pass MCP servers to the LLM request: <pre><code class="language-typescript">body: JSON.stringify({ model: "llama-3.3-70b-versatile", messages: [{ role: "user", content: message }], tools: [ { type: "mcp", server_label: "OrderServer", server_url: `http://0.0.0.0:${PORT}/mcp`, server_description: "Get the status of an order by its ID", }, { type: "mcp", server_label: "Slack", server_url: "https://mcp.slack.com/mcp", server_description: "Send and read Slack messages", headers: { Authorization: `Bearer ${process.env.SLACK_BOT_TOKEN}`, }, }, ], }) </code></pre> We can also use local MCP servers instead of remote URLs by connecting through transports such as <code>StdioClientTransport</code>. In that case, we connect locally, discover the available tools, and expose them to the LLM. Now if the user sends: <pre><code class="language-json">{ "message": "What is status of order 123" } </code></pre> The LLM decides whether a tool is needed, MCP exposes and executes the tool, and the final response is returned to the user. The flow becomes: /chat api -> LLM -> MCP Tool -> Tool Result -> Tool Response" style="display:block;margin:0 auto" width="1774" height="887" loading="lazy"> This standardization makes integrations far more reusable: instead of rewriting glue logic for each new connector, teams can register MCP-compliant tools and let the orchestrator and model handle discovery and invocation. <h2 id="heading-so-what-does-langchain-actually-do">So What Does LangChain Actually Do?</h2> I initially thought LangChain was simply another wrapper around LLM APIs, but it is better understood as an orchestration framework for AI workflows. Tools let an LLM perform actions. MCP standardizes how tools are exposed. LangChain helps coordinate models, tools, and application logic to build multi-step workflows. For example: <blockquote> User: Find flights, compare prices, book hotel, send confirmation. </blockquote> Now the system may need to: <ul> <li>Check order status </li> <li>Decide whether support is needed </li> <li>Create a support ticket </li> <li>Generate the final response </li> </ul> Without orchestration, you would manually control each step. LangChain helps manage this flow. To use LangChain, Install the required packages: <pre><code class="language-json">npm install express langchain @langchain/groq </code></pre> We'll reuse the same tool functions from earlier: <pre><code class="language-typescript">import express from "express"; import { createAgent } from "langchain"; import { ChatGroq } from "@langchain/groq"; const app = express(); app.use(express.json()); const agent = createAgent({ model: new ChatGroq({ model: "llama-3.3-70b-versatile", apiKey: GROQ_API_KEY, }), tools: [ { name: "getOrderStatus", description: "Get order status", execute: ({ id }) => getOrderStatus(id), // we have this function above }, { name: "createSupportTicket", description: "Create support ticket", execute: ({ id }) => createSupportTicket(id), //imagine a function that creates a support ticket }, ], }); app.post( "/chat", async (req, res) => { const { message } = req.body; const response = await agent.invoke({ messages: [ { role: "user", content: message, }, ], }); res.json({ reply: response.messages ?.at(-1) ?.text, }); } ); app.listen(3000); </code></pre> Now the flow becomes: LangChain doesn't replace tools or MCP. It sits above them and coordinates how everything works together. <h2 id="heading-putting-it-together">Putting It Together</h2> A modern AI application usually has multiple layers working together. The LLM handles reasoning and language generation. Tools perform real operations such as reading data, calling APIs, or executing actions. MCP helps standardize how those tools are exposed and accessed. LangChain helps orchestrate the interaction between models, tools, and workflows. By separating these responsibilities, applications become easier to extend, maintain, and scale. The goal is more than just generating text. You want to be able to build systems that can reason, retrieve information, take actions, and reliably solve real user problems. LLM -> LangChain -> MCP -> Tools -> Systems & Data" style="display:block;margin:0 auto" width="1536" height="1024" loading="lazy"> <h2 id="heading-what-i-built-while-learning-this">What I Built While Learning This</h2> After understanding the concepts above, I wanted to reduce some of this setup for my own projects. As I experimented, I noticed most applications recreate the same plumbing over and over: connecting an LLM, wiring up tools, managing execution, and exposing orchestration patterns. So I built a small open-source toolkit to reduce that setup. The goal was simple: you should be able to focus on business logic instead of wiring AI infrastructure. Current capabilities: <ul> <li>LLM integration </li> <li>Tool registration </li> <li>Tool execution </li> <li>Chat orchestration </li> <li>LangChain support </li> <li>Extensible architecture </li> </ul> <h3 id="heading-packages">Packages:</h3> AI Chat Widget: <a href="https://www.npmjs.com/package/ai-chat-toolkit-widget">https://www.npmjs.com/package/ai-chat-toolkit-widget</a> AI Chat Server: <a href="https://www.npmjs.com/package/ai-chat-toolkit-server">https://www.npmjs.com/package/ai-chat-toolkit-server</a> GitHub Repository: <a href="https://github.com/sudheeshshetty/ai-chat-toolkit">https://github.com/sudheeshshetty/ai-chat-toolkit</a> To build a server using the toolkit: <pre><code class="language-typescript">npm install express ai-chat-toolkit-server </code></pre> Create the chat server: <pre><code class="language-typescript">const aiChat = new AiChatServer({ path: "/my-chat", provider: "groq", apiKey: process.env.API_KEY, model: process.env.MODEL || "llama-3.3-70b-versatile", cors: { origin: "http://localhost:5174", }, orchestration: "langchain", maxToolRounds: 6, systemPrompt: "You are a helpful operations assistant for a demo store. Keep answers concise.", }); </code></pre> Add your tools: <pre><code class="language-typescript">aiChat.addTools([ { name: "...", description: "...", inputSchema: { ... }, handler: async (input) => { /* runs in Node */ }, }, ]); </code></pre> Attach it to your Express app: <pre><code class="language-typescript">aiChat.attach(app); </code></pre> Now <code>/my-chat</code> is exposed in your Express server and can be used directly. You can also use <code>ai-chat-toolkit-widget</code> if you want to skip building the chat UI. Examples are available in the repository, so you can try it out quickly. A quick glance of one of the examples: If you find it useful, I’d appreciate a star, feedback, or contributions on GitHub as I continue improving the developer experience and exploring new ideas. Thanks for reading — I hope this helped make LLMs, tools, MCP, and LangChain feel a little less magical and a lot more practical. </article> <article> <h1> Building a Website in 2026: What Matters More Than Your Tech Stack </h1> Manish Shivanandhan — Sun, 14 Jun 2026 02:17:56 +0000 For years, developers have debated which technology stack was best for building websites. Some preferred React. Others chose Vue, Angular, Svelte, or server-side frameworks such as Laravel and Django. Entire conferences, blogs, and social media discussions have been dedicated to comparing frameworks and programming languages. In 2026, those debates matter less than many developers think. A modern website can be built with almost any mature framework and still perform well. The bigger challenge is making sure people can actually find, trust, and use that website. Discoverability, performance, infrastructure, structured data, and AI search visibility now have a greater impact on success than the choice between competing frontend libraries. The websites that win today aren't necessarily built with the most fashionable technologies. They're built with a strong foundation that helps users and search systems understand, access, and trust their content. In this article, we'll look at what really matters when building a website these days. We'll explore why performance, hosting, domain management, structured data, and content quality often have a bigger impact than the technology stack itself. We'll also examine how AI-powered search is changing the way people find information online and what developers can do to improve their website's visibility. <h3 id="heading-what-well-cover">What We'll Cover:</h3> <ul> <li><a href="#heading-the-tech-stack-has-become-a-commodity">The Tech Stack Has Become a Commodity</a> </li> <li><a href="#heading-performance-is-still-a-competitive-advantage">Performance Is Still a Competitive Advantage</a> </li> <li><a href="#heading-domains-and-infrastructure-still-matter">Domains and Infrastructure Still Matter</a> </li> <li><a href="#heading-hosting-is-no-longer-just-about-servers">Hosting Is No Longer Just About Servers</a> </li> <li><a href="#heading-structured-data-has-become-essential">Structured Data Has Become Essential</a> </li> <li><a href="#heading-the-rise-of-ai-search-and-answer-engines">The Rise of AI Search and Answer Engines</a> </li> <li><a href="#heading-content-quality-is-more-important-than-ever">Content Quality Is More Important Than Ever</a> </li> <li><a href="#heading-user-experience-is-the-new-differentiator">User Experience Is the New Differentiator</a> </li> <li><a href="#heading-the-future-is-about-outcomes-not-frameworks">The Future Is About Outcomes, Not Frameworks</a> </li> </ul> <h2 id="heading-the-tech-stack-has-become-a-commodity">The Tech Stack Has Become a Commodity</h2> The web development ecosystem has matured significantly over the past decade. Most modern frameworks provide similar capabilities. They support <a href="https://www.freecodecamp.org/news/a-brief-introduction-to-web-components/">component-based development</a>, <a href="https://www.freecodecamp.org/news/rendering-patterns/">server-side rendering</a>, API integrations, authentication systems, and performance optimization. As a result, the gap between frameworks has narrowed. A poorly optimized website built with the latest framework will often perform worse than a well-optimized website built with older technology. Users rarely care whether a page was built with React, Vue, or another framework. They care whether it loads quickly, works on mobile devices, and provides useful information. Businesses care even more about outcomes. They want traffic, conversions, customer engagement, and revenue growth. None of those metrics improve simply because a team adopted a trendy technology stack. This shift has forced development teams to focus on factors that have a direct impact on visibility and user experience. <h2 id="heading-performance-is-still-a-competitive-advantage">Performance Is Still a Competitive Advantage</h2> Despite advances in hosting and frontend tooling, <a href="https://www.freecodecamp.org/news/performance-testing-for-web-applications/">website performance</a> remains one of the strongest predictors of user satisfaction. Research consistently shows that slower websites lead to higher <a href="https://www.semrush.com/blog/bounce-rate/">bounce rates</a> and lower conversion rates. Users expect pages to load almost instantly. Even a delay of a few seconds can cause visitors to abandon a website before interacting with its content. Modern performance optimisation goes beyond minimising JavaScript bundles. Teams must consider image optimisation, edge caching, content delivery networks, lazy loading, and server response times. For example, an e-commerce website might reduce page load times by serving product images in modern formats such as WebP, implementing lazy loading for below-the-fold content, and using a CDN to deliver assets from locations closer to shoppers. These improvements often produce a more noticeable impact than migrating to a new frontend framework. Many websites spend months migrating between frameworks while ignoring performance bottlenecks that would have a much larger impact on user experience. In practice, improving page speed often delivers greater business value than rebuilding an application using a different frontend stack. Performance has also become increasingly important for search visibility. Search engines reward websites that provide a fast and reliable user experience. A technically impressive website that loads slowly is unlikely to achieve its full potential. <h2 id="heading-domains-and-infrastructure-still-matter">Domains and Infrastructure Still Matter</h2> Developers often focus on application code while overlooking the infrastructure that supports it. A website's domain remains one of its most important digital assets. Domain management affects security, reliability, and long-term brand ownership. Choosing a reputable registrar and maintaining proper DNS configuration are critical responsibilities. A simple example is setting up DNS failover and enabling registrar-level security features such as domain lock and two-factor authentication. These measures help prevent outages and unauthorised domain transfers that could take a website offline. For many teams, services such as <a href="https://www.namecheap.com/">Namecheap</a> and GoDaddy provide a straightforward way to manage domain registration, DNS records, SSL certificates, and related infrastructure. While these tasks may seem mundane compared to application development, they directly influence website availability and security. <a href="https://www.freecodecamp.org/news/how-dns-works-the-internets-address-book/">DNS performance</a> has become particularly important as websites adopt distributed architectures. Modern applications frequently rely on multiple services, APIs, content delivery networks, and edge platforms. A poorly configured DNS setup can introduce unnecessary latency and create reliability issues. Infrastructure decisions also influence scalability. As traffic grows, websites must continue delivering fast and consistent experiences without requiring major architectural changes. The most successful development teams treat infrastructure as a strategic asset rather than an afterthought. <h2 id="heading-hosting-is-no-longer-just-about-servers">Hosting Is No Longer Just About Servers</h2> In the past, hosting primarily involved renting a server and deploying application code. Today, hosting platforms offer far more than compute resources. They provide global content delivery networks, automatic scaling, integrated security features, <a href="https://www.hostinger.com/in/tutorials/best-observability-tools?utm_source=google&utm_medium=cpc&utm_id=11181890096&utm_campaign=Generic-Tutorials-DSA-t1%7CNT:Se%7CLang:EN%7CLO:IN&utm_term=&utm_content=798975275269&gad_source=1&gad_campaignid=11181890096&gbraid=0AAAAADMy-hZNKr2zB2PoiZCDVXWmMXbaA&gclid=Cj0KCQjwof_QBhCgARIsADaMzOdeTB4LogkEU5Tg4r1U90UwKS3_-I-_yR5rTyGUdjeBDBoOwXaiIVgaAh2zEALw_wcB">observability tools</a>, and deployment automation. The rise of edge computing has changed how websites are delivered. Content can now be served from locations close to users, reducing latency and improving responsiveness. A media website experiencing a sudden traffic spike after a story goes viral can benefit from automatic scaling and edge caching, maintaining fast load times without requiring engineers to provision additional infrastructure manually. Modern hosting decisions affect everything from performance and reliability to search rankings and customer satisfaction. This means developers should evaluate hosting providers based on outcomes rather than specifications. Raw server resources matter less than factors such as uptime, deployment speed, geographic distribution, and operational simplicity. A website that remains available during traffic spikes creates a better user experience than one that struggles under load, regardless of the underlying technology stack. <h2 id="heading-structured-data-has-become-essential">Structured Data Has Become Essential</h2> One of the most overlooked aspects of modern website development is structured data. Search engines and AI systems increasingly rely on structured information to understand website content. Schema markup helps machines identify products, articles, organisations, events, reviews, and many other types of information. For instance, an online store can use a Product schema to display pricing and availability information in search results. At the same time, a recipe website can implement a Recipe schema to surface cooking times, ratings, and ingredients directly within search experiences. Without structured data, websites force search systems to infer meaning from unstructured text. This increases the likelihood of misinterpretation. Structured data improves the chances that content will appear in rich search results, featured snippets, knowledge panels, and other enhanced search experiences. More importantly, structured data provides context that helps emerging AI systems understand content accurately. As search evolves beyond traditional blue links, machine-readable information becomes increasingly valuable. Developers who ignore structured data risk making their websites less visible, even if the content itself is excellent. <h2 id="heading-the-rise-of-ai-search-and-answer-engines">The Rise of AI Search and Answer Engines</h2> Perhaps the biggest shift in website visibility is the growth of AI-powered search experiences. Users increasingly ask questions directly to AI assistants rather than typing keywords into traditional search engines. These systems generate answers by combining information from multiple sources and presenting results in a conversational format. This change creates new challenges for website owners. Ranking on Google is no longer the only goal. Websites must also be structured in ways that help AI systems understand, retrieve, and reference their content. A software company publishing detailed comparison guides, implementation tutorials, and clearly structured FAQs is more likely to be cited in AI-generated responses than a competitor relying solely on promotional landing pages. This is where <a href="https://www.semrush.com/blog/answer-engine-optimization">Answer Engine Optimisation (AEO)</a> is becoming important. Unlike traditional SEO, which focuses on improving rankings in search results, AEO focuses on increasing the likelihood that content will be selected, cited, or referenced within AI-generated responses. AI-powered search systems evaluate content differently from traditional search engines. Rather than simply matching keywords, they attempt to identify sources that provide clear explanations, authoritative information, and direct answers to user questions. Content that is well structured, factually accurate, and easy to interpret tends to perform better in these environments. Platforms such as <a href="https://www.dirjournal.com/">DirJournal</a>, an answer engine optimisation platform, help businesses understand how their content appears across AI-driven search environments. As teams adapt to changing search behaviour, they're increasingly monitoring not only search rankings but also the frequency with which AI systems reference their brands, products, and expertise. The websites that succeed in this environment are often those that publish clear, authoritative content supported by strong technical foundations. In many cases, the same practices that improve traditional SEO also support AI discoverability. Fast websites, structured data, authoritative content, and clear information architecture all contribute to better visibility. <h2 id="heading-content-quality-is-more-important-than-ever">Content Quality Is More Important Than Ever</h2> Technology can improve delivery, but content remains the primary reason users visit a website. AI systems are becoming increasingly effective at identifying expertise, authority, and relevance. Thin content designed solely for search rankings is becoming less effective. Modern websites must provide genuine value. They need original insights, practical examples, clear explanations, and trustworthy information. For example, a cybersecurity vendor might publish original research on emerging threats, while a healthcare provider could create evidence-based patient guides reviewed by medical professionals. Content grounded in expertise tends to earn greater trust and visibility. Developers building content-driven websites should think beyond page views and rankings. The goal is to create resources that answer real questions and solve real problems. Content that demonstrates expertise is more likely to earn links, generate engagement, and be referenced by both search engines and AI systems. The websites that stand out now are those that prioritize usefulness over optimization tricks. <h2 id="heading-user-experience-is-the-new-differentiator">User Experience Is the New Differentiator</h2> As technology becomes more accessible, user experience becomes a larger competitive advantage. Visitors expect intuitive navigation, accessible interfaces, responsive layouts, and consistent performance across devices. Simple improvements such as reducing the number of checkout steps, increasing button sizes on mobile devices, or ensuring keyboard navigation works correctly can significantly improve usability and conversion rates. Poor user experiences create friction that drives users away regardless of how advanced the underlying technology may be. <a href="https://www.freecodecamp.org/news/the-web-accessibility-handbook/">Accessibility deserves particular attention</a>. Websites should be usable by people with diverse abilities and assistive technologies. Accessibility improvements often enhance usability for all visitors while supporting compliance requirements. The best websites combine technical excellence with thoughtful design. They remove obstacles and help users accomplish their goals quickly and efficiently. <h2 id="heading-the-future-is-about-outcomes-not-frameworks">The Future Is About Outcomes, Not Frameworks</h2> The web development industry has reached a point where most modern frameworks are capable of delivering excellent results. The real challenge is no longer choosing the perfect technology stack. Success depends on building websites that are fast, discoverable, reliable, secure, and understandable to both humans and machines. Performance optimization, domain management, hosting strategy, structured data, content quality, and AI search visibility now play a larger role in determining outcomes. These days, the websites that succeed aren't necessarily built with the newest technologies. They're built with the strongest foundations. Developers who focus on those foundations will create websites that continue to perform well regardless of how search engines, AI systems, or frontend frameworks evolve in the years ahead. Hope you enjoyed this article. You can <a href="https://linkedin.com/in/manishmshiva">connect with me on LinkedIn</a>. </article> </main></body></html>

Web Development - freeCodeCamp.org

How to Implement Role-Based Access Control in a Node.js REST API with JWT

Table of Contents

What You'll Learn

Prerequisites

What We'll Build

Project Setup

Setting Up the In-Memory Data Store

Building the Auth Routes

Building the RBAC Middleware

Building the Protected Routes

Putting It All Together

Testing the API

Step 1: Register Users with Different Roles

Step 2: Log in and Get a Token

Step 3: Test Role-based Access

Step 4: Decode the JWT to See the Role

Key Takeaways

Conclusion

How to Build a Browser-Based PDF OCR to Text Converter Using JavaScript

Table of Contents

Why PDF OCR Is Useful

How PDF OCR Works

Project Setup

What Libraries Are We Using?

Creating the Upload Interface

Drag & Drop PDF Here

Previewing Uploaded PDF Pages

Configuring OCR Settings

Improving OCR Accuracy Before Processing

Extracting Text from the PDF

Tracking OCR Progress

Understanding OCR Confidence Scores

Optimizing OCR Accuracy

Reviewing the Extracted Text

Exporting the OCR Results

Demo: How the PDF OCR Tool Works

Step 1: Upload Your PDF

Step 2: Preview the Uploaded PDF

Step 3: Configure OCR Settings

Step 4: Start OCR Processing

Step 5: Monitor Processing Progress

Step 6: Review OCR Confidence Scores

Step 7: Review the Extracted Text

Step 8: Export the Results

Performance Optimization Tips

Important Notes from Real-World Use

Common Mistakes to Avoid

Conclusion

How to Build Production-Ready Card Components with shadcn/ui

Table of Contents

Prerequisites

Why shadcn/ui?

What is Shadcn Space?

What You'll Build

How to Set Up the CLI Registry

How to Build the Preview Card (card-02)

What the Preview Card Does

How to Install the Preview Card

The Component Code

Serenity Residential Home

1. Group hover behavior

2. Overflow clipping on image zoom

3. Logical border properties in the amenity row

Live Preview:

How to Build the Analytics Card (card-05)

What the Analytics Card Does

How to Install the Analytics Card

The Component Code

1. Optional props with a default dataset

2. Conditional badge colors with cn()

3. Separators only between metrics, not after the last one

4. Absolute-positioned decorative image

Live Preview:

How to Build the Statistics Card (card-06)

What the Statistics Card Does

How to Install the Statistics Card

The Component Code

{item.title}

{item.subtitle}

2. Conditional badge colors with `cn()`

3. Removing the last border with `last:`

4. Why `"use client"` is needed here

4. `suppressHydrationWarning` on the delivery date span

The `cn()` Utility

`last:` Tailwind Variant

`"use client"` in Next.js App Router

`suppressHydrationWarning`