DEV Community: MD Zoheb

Beyond 'eval()': How I Built a Step-by-Step Math Calculator That Explains Its Work with AI

MD Zoheb — Fri, 04 Sep 2026 02:10:03 +0000

Building a calculator that returns an answer takes little code.

Building one that explains how it reached that answer creates a different problem.

Take this expression:

12 + 6 × 3

JavaScript can calculate the result with simple code.

const result = 12 + 6 * 3;

console.log(result);
// 30

That gives the correct answer.

It does not explain the work.

A student may need to see this:

12 + 6 × 3

Step 1:
Multiply 6 by 3.

6 × 3 = 18

Step 2:
Add 12 and 18.

12 + 18 = 30

Final answer:
30

That difference between calculating and explaining became the main challenge when I worked on a step-by-step math calculator.

I wanted something that could handle more than basic arithmetic.

The calculator needed to work with equations, fractions, algebra, percentages, calculus, word problems, and other math questions.

I also wanted clean mathematical notation.

That meant solving several separate problems:

understand the user's input
solve the problem
produce useful steps
format mathematical expressions
render those expressions in the browser
check the result where possible
keep the API secure

I ended up using an AI model together with normal application code, LaTeX, and MathJax.

The AI handles the flexible reasoning.

LaTeX describes the math.

MathJax turns the LaTeX into readable mathematical notation.

JavaScript handles the interface and application logic.

Why `eval()` is not enough

A basic JavaScript calculator often starts with something like this:

const expression = "12 + 6 * 3";
const answer = eval(expression);

console.log(answer);

There are two problems with this approach.

The first problem is security.

Passing raw user input to eval() can execute JavaScript. That makes it a poor choice for a public calculator.

The second problem matters even more here.

eval() gives me this:

It does not give me this:

6 × 3 = 18
12 + 18 = 30

It also cannot explain why multiplication happens before addition.

The limitation becomes clearer with algebra.

Consider:

2x + 5 = 17

A useful result should look like this:

2x + 5 = 17

Subtract 5 from both sides.

2x = 12

Divide both sides by 2.

x = 6

JavaScript does not understand 2x + 5 = 17 as a normal JavaScript expression.

A step-by-step solver needs more than expression evaluation.

Hard-coding every possible solution gets messy

One option would be to write custom solving logic for every type of math.

I could start with addition.

Then subtraction.

Then multiplication.

Then division.

Then fractions.

Then percentages.

Then linear equations.

Then quadratic equations.

Then powers and roots.

Then logarithms.

Then derivatives.

Then integrals.

The amount of code would keep growing.

Even one category contains many different forms.

A linear equation might look like this:

2x + 5 = 17

It might also look like this:

4(x - 2) = 20

Or:

3x + 7 = x + 19

The steps change for each case.

Word problems create another issue.

A rectangle has a length of 12 cm and a width of 7 cm.
What is its area?

A normal expression parser first needs to understand the sentence.

It then needs to identify the correct formula.

Only after that can it calculate the answer.

I did not want to create thousands of explanation rules by hand.

That is where an AI model became useful.

Where AI fits

I do not treat the AI model as the whole application.

It handles the part that benefits from flexible reasoning and language.

The rest of the system still uses normal code.

A simplified flow looks like this:

User enters a problem
        ↓
Application processes the input
        ↓
Solver receives the problem
        ↓
AI works through the solution
        ↓
AI returns structured output
        ↓
Application checks the response
        ↓
MathJax formats the math
        ↓
Steps appear in the browser

The model can understand different forms of math without requiring one hard-coded path for every possible question.

That does not mean the model gets full control.

The application still decides how the response should look and how it should reach the screen.

I ask for structured output

I do not want the model to return a random block of text.

A response like this is difficult to control:

Okay! Let's solve this problem. First we need to...

The wording may change on every request.

The frontend also has to guess where one step ends and another begins.

Structured output works better.

For example:

{
  "finalAnswer": "\\(x = 6\\)",
  "steps": [
    {
      "explanation": "Start with the equation.",
      "math": "\\[2x + 5 = 17\\]"
    },
    {
      "explanation": "Subtract 5 from both sides.",
      "math": "\\[2x = 12\\]"
    },
    {
      "explanation": "Divide both sides by 2.",
      "math": "\\[x = 6\\]"
    }
  ]
}

Now the roles stay clear.

The AI produces the solution data.

The application controls the interface.

This gives me much more predictable output.

Why I use LaTeX

Getting the correct steps from AI solves only part of the problem.

Math can look bad in plain text.

Take the quadratic formula.

The AI could return:

x = (-b +- sqrt(b^2 - 4ac)) / 2a

A human can understand it.

It does not look like proper mathematical notation.

LaTeX gives the model a standard way to describe the expression.

x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}

The same approach works for fractions:

\frac{3x + 2}{x - 5}

Square roots:

\sqrt{x^2 + 9}

Powers:

x^{12}

Integrals:

\int_0^5 x^2 \, dx

Matrices:

\begin{bmatrix}
1 & 2 \\
3 & 4
\end{bmatrix}

LaTeX gives the application one consistent format for mathematical expressions.

The AI does not need to invent a different visual style for every problem.

AI gives me LaTeX. MathJax makes it readable.

LaTeX is still text.

A browser does not automatically turn this:

\[\frac{x+2}{3}=7\]

into a properly formatted equation.

That is where MathJax comes in.

The full flow looks more like this:

User Input
    ↓
Input Processing
    ↓
Solver Router
    ↓
AI or Local Math Engine
    ↓
Validation
    ↓
Structured JSON
    ↓
LaTeX Expressions
    ↓
MathJax
    ↓
Step-by-Step Interface

The AI decides what the solution should contain.

LaTeX describes the mathematical notation.

MathJax renders that notation inside the page.

Each part has one clear job.

I tell the model exactly how to format math

The prompt matters a lot.

I do not send only:

Solve this:
2x + 5 = 17

That gives the model too much freedom.

I define the expected output.

A simplified prompt might look like this:

Solve the math problem step by step.

Keep each explanation short.

Do not skip important operations.

Return mathematical expressions as LaTeX.

Use \( ... \) for inline math.

Use \[ ... \] for equations that should appear on their own line.

Do not return HTML.

Do not place LaTeX inside Markdown code blocks.

Return valid JSON.

Use this structure:

{
  "finalAnswer": "",
  "steps": [
    {
      "explanation": "",
      "math": ""
    }
  ]
}

I can also add instructions for specific types of problems.

For algebra:

Show what operation happens to both sides of the equation.

For fractions:

Show the common denominator when one is required.

For calculus:

State the rule used before applying it.

The prompt does not need to teach mathematics from scratch.

The model already handles the reasoning.

The prompt defines how I want the result delivered.

JSON escaping matters with LaTeX

There is one small detail that can cause confusing bugs.

LaTeX uses backslashes.

For example:

\frac{3}{4}

JSON strings also use backslashes for escaping.

That means serialized JSON may contain:

{
  "math": "\\[\\frac{3}{4}\\]"
}

The double backslashes are normal.

After JavaScript parses the JSON, the string becomes the LaTeX expression that MathJax needs.

This matters for commands such as:

\frac
\sqrt
\times
\div
\int

Incorrect escaping can break otherwise valid AI output.

Loading MathJax

A page can load MathJax from a content delivery network.

A simple setup can look like this:

<script>
window.MathJax = {
  tex: {
    inlineMath: [
      ['\\(', '\\)']
    ],
    displayMath: [
      ['\\[', '\\]']
    ]
  }
};
</script>

<script
  defer
  src="https://cdn.jsdelivr.net/npm/mathjax@4/tex-svg.js">
</script>

I prefer explicit delimiters.

Inline math uses:

\( x = 6 \)

Display math uses:

\[ x = 6 \]

This also avoids depending only on dollar signs.

Dollar signs can appear in normal text.

Take this question:

A $50 product gets a 20% discount.
What is the new price?

Using $...$ as the only delimiter can create problems when the input contains currency.

The $...$ and \[...\] delimiters make the boundary much clearer.

Dynamic AI output needs another MathJax step

This part matters in an AI calculator.

MathJax can process equations that already exist when the page loads.

AI responses arrive later.

The user enters a problem.

JavaScript sends a request.

The server returns the solution.

JavaScript then adds those new steps to the page.

MathJax needs to process that new content.

A simplified renderer could look like this:

async function renderSolution(solution) {
  const container = document.querySelector("#solution");

  container.replaceChildren();

  solution.steps.forEach((step, index) => {
    const section = document.createElement("section");

    const heading = document.createElement("h3");
    heading.textContent = `Step ${index + 1}`;

    const explanation = document.createElement("p");
    explanation.textContent = step.explanation;

    const math = document.createElement("div");
    math.textContent = step.math;

    section.append(
      heading,
      explanation,
      math
    );

    container.appendChild(section);
  });

  const finalAnswer = document.createElement("div");

  finalAnswer.textContent =
    `Final answer: ${solution.finalAnswer}`;

  container.appendChild(finalAnswer);

  await MathJax.typesetPromise([container]);
}

The important part is:

await MathJax.typesetPromise([container]);

The AI response already exists inside the container at that point.

MathJax scans it and finds the LaTeX delimiters.

It then renders the equations.

Without that final step, users would see raw strings such as:

\[\frac{3}{4} + \frac{1}{2}\]

instead of properly formatted math.

I keep text and equations separate

I prefer this structure:

{
  "explanation": "Subtract 5 from both sides.",
  "math": "\\[2x = 12\\]"
}

instead of:

{
  "step": "Subtract 5 from both sides so \\(2x = 12\\)"
}

Keeping them separate gives the frontend more control.

The explanation can use normal paragraph styling.

The equation can have more space around it.

MathJax only needs to handle the mathematical part.

The layout also becomes easier to adapt for phones.

I do not ask the AI to generate HTML

It might seem easier to ask the model for this:

<p>Subtract 5 from both sides.</p>
<div>2x = 12</div>

I avoid that approach.

The model should return data.

The application should create the markup.

I prefer:

{
  "explanation": "Subtract 5 from both sides.",
  "math": "\\[2x = 12\\]"
}

Then JavaScript creates the elements.

This keeps the application structure predictable.

It also gives the model less control over the page.

I would avoid doing this with raw model output:

container.innerHTML = modelResponse;

AI output should count as untrusted input.

Creating elements and using textContent gives the application much more control.

explanation.textContent = step.explanation;
math.textContent = step.math;

MathJax can process the mathematical string after JavaScript adds it to the document.

The model controls the equation.

It does not control the page markup.

The browser should not contain the AI API key

An AI-powered calculator needs access to an AI service.

That usually means an API key.

The key should stay on the server.

It should not appear inside public browser JavaScript.

This is unsafe:

const API_KEY = "my-secret-api-key";

Anyone can inspect the page source or network activity.

Instead, the browser sends the problem to an endpoint on my own server.

A simplified example looks like this:

async function solveProblem(problem) {
  const response = await fetch("/api/solve", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      problem
    })
  });

  if (!response.ok) {
    throw new Error("Unable to solve the problem");
  }

  return response.json();
}

The server talks to the AI provider.

The browser never receives the secret key.

The server can also apply rate limits and input limits before spending money on a model request.

AI still needs verification

AI gives the calculator flexibility.

It does not guarantee perfection.

A language model can make calculation mistakes.

It can miss a negative sign.

It can misunderstand ambiguous input.

It can also give a clean explanation for an incorrect answer.

That means the application should verify whatever it can.

Take:

2x + 5 = 17

Suppose the model returns:

x = 6

The application can substitute 6 back into the equation.

2(6) + 5 = 17

12 + 5 = 17

17 = 17

That gives another signal that the answer works.

Basic arithmetic can use deterministic code for checks.

A simple comparison might look like this:

function verifyBasicArithmetic(expected, modelAnswer) {
  return Number(expected) === Number(modelAnswer);
}

More advanced problems need more advanced verification.

The main idea stays simple:

Use AI for explanation and flexible reasoning. Verify with deterministic tools where possible.

A hybrid system makes more sense

AI does not need to calculate everything.

Take:

25 × 8

JavaScript can solve that perfectly well.

const answer = 25 * 8;

Sending every basic multiplication problem to an AI model adds cost and latency without much benefit.

A calculator can route different problems to different systems.

A simplified version might look like this:

function chooseSolver(problem) {
  if (isBasicArithmetic(problem)) {
    return "local";
  }

  return "ai";
}

Simple arithmetic can use local code.

More complex questions can use the AI layer.

A larger system could also use dedicated math libraries for symbolic work.

Different tools can handle different jobs.

There is no good reason to force every problem through one solver.

Word problems show where AI helps

Natural-language math questions create a good use case for AI.

Take this:

A train travels 240 kilometers in 3 hours.
What is its average speed?

A traditional calculator first needs to extract:

distance = 240 km
time = 3 hours

Then it needs to identify the formula:

speed = distance ÷ time

Then it calculates:

240 ÷ 3 = 80

An AI model can understand the sentence and produce those steps together.

A structured response might look like this:

{
  "finalAnswer": "\\(80\\text{ km/h}\\)",
  "steps": [
    {
      "explanation": "Use the average speed formula.",
      "math": "\\[\\text{speed} = \\frac{\\text{distance}}{\\text{time}}\\]"
    },
    {
      "explanation": "Insert the values.",
      "math": "\\[\\text{speed} = \\frac{240}{3}\\]"
    },
    {
      "explanation": "Calculate the result.",
      "math": "\\[\\text{speed} = 80\\text{ km/h}\\]"
    }
  ]
}

MathJax can then turn those LaTeX strings into readable equations.

This moves the project beyond a normal calculator.

The system now has to understand what the user means before solving the calculation.

Users do not always type clean math

People enter the same problem in different ways.

One person may type:

sqrt 144

Another may type:

square root of 144

Another may use:

√144

All three mean the same thing.

Input processing can clean some common formatting before sending the request to a solver.

A basic example looks like this:

function normalizeInput(input) {
  return input
    .trim()
    .replace(/\s+/g, " ");
}

Real math normalization needs more care.

Changing mathematical input too aggressively can change its meaning.

I prefer conservative cleanup and let the solver interpret the actual expression.

Invalid problems need a clear error path

A solver should not invent an answer when the input does not make sense.

Take:

5 + × 9

The application should return a clear error.

For example:

{
  "status": "error",
  "message": "I could not read this expression clearly."
}

That works better than showing a confident but unreliable result.

The same rule applies when the AI response does not match the expected JSON structure.

The application should reject malformed output instead of trying to guess what the model meant.

Public AI tools also need limits

A public calculator needs request limits.

Without them, someone could submit a huge block of unrelated text.

Empty input should fail before reaching the model.

if (!problem.trim()) {
  return error("Enter a math problem first.");
}

Long input can also have a limit.

if (problem.length > MAX_PROBLEM_LENGTH) {
  return error("The problem is too long.");
}

The output can have limits too.

A solution with 40 tiny steps often makes the problem harder to follow.

The goal is not to generate the longest explanation.

The goal is to show enough work for someone to understand the calculation.

The interface still matters

A correct answer can still feel difficult to use.

I wanted the solution to have a clear order:

Problem
↓
Final Answer
↓
Step-by-Step Work

Each equation needs enough room.

The explanation should stay short.

Important operations should stand out.

Complex fractions and equations should remain readable on smaller screens.

The user should also be able to enter another problem without reloading the entire page.

The AI model handles the reasoning.

MathJax handles the notation.

The interface still decides whether the final experience feels easy to follow.

A live version

I built a working version around these ideas.

The Step by Step Math Calculator uses AI to help solve different types of math questions and explain the work behind the answer.

The important part for me was not just showing a result.

I wanted the calculator to turn the solution into readable steps and properly formatted mathematical expressions.

That required much more than sending a prompt to an AI model.

The architecture I would use again

The main pieces now look like this:

┌───────────────────────────┐
│        User Input         │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│      Input Processing     │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│       Solver Router       │
└────────┬───────────┬──────┘
         │           │
         ▼           ▼
┌──────────────┐ ┌──────────────┐
│  Local Math  │ │   AI Model   │
└───────┬──────┘ └───────┬──────┘
        │                │
        └────────┬───────┘
                 │
                 ▼
┌───────────────────────────┐
│       Verification        │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│      Structured JSON      │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│       LaTeX Output        │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│          MathJax          │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│    Step-by-Step Result    │
└───────────────────────────┘

This separation also makes the project easier to change.

A different AI model can replace the current one.

A stronger math engine can handle more deterministic calculations.

The frontend does not need to know how every solver works.

MathJax only needs valid LaTeX.

Each layer can change without rebuilding the whole project.

The part I underestimated

At first, the obvious challenge looked like solving the math.

That turned out to be only one part.

The harder product problem involved moving from:

input → answer

to:

input
  ↓
understand
  ↓
solve
  ↓
verify
  ↓
explain
  ↓
format
  ↓
render

AI helps with understanding and explaining.

Normal code handles security and application logic.

Deterministic math can verify some results.

LaTeX provides a standard format for mathematical expressions.

MathJax makes those expressions readable inside the browser.

That combination works much better than asking one tool to handle everything.

I do not need an AI model to tell me that:

2 + 2 = 4

The interesting cases look more like this:

A shop reduces a $120 item by 15%.
Sales tax of 5% applies after the discount.
What is the final price?

The calculator has to understand the order of operations in the real-world problem.

It needs to perform the calculations.

It needs to explain each step.

It needs to format percentages and equations.

It needs to display the result clearly.

That is where a step-by-step calculator becomes much more interesting than eval().

How to Choose the Right Image Format for Web Performance

MD Zoheb — Sat, 16 May 2026 12:36:49 +0000

Images can make a website feel rich, clear, and professional. They can also make it slow, heavy, and frustrating if the wrong format is used. Many website owners upload images without thinking about file type. A photo becomes PNG. A logo becomes JPG. A large hero image stays uncompressed. Then the page loads slowly, mobile users leave, and performance scores drop.

Choosing the right image format is not just a design decision. It directly affects loading speed, bandwidth, SEO, Core Web Vitals, and user experience. A good image format keeps the visual quality high while reducing the file size as much as possible.

The good news is that the basic rules are not complicated. Once you understand when to use JPG, PNG, WebP, SVG, and newer formats like AVIF, it becomes much easier to prepare images correctly for the web.

Why Image Format Matters for Website Speed

Every image on a page has a size. The browser has to download that image before the user can fully see it. If the image is large, the page takes longer to load. This is especially noticeable on mobile networks, slower connections, or pages with many images.

A single image can sometimes be larger than all the HTML, CSS, and JavaScript on a page combined. That is why image optimization is one of the easiest ways to improve web performance. The web.dev image optimization guide also explains how image size, dimensions, compression, and delivery can affect loading performance.

The image format affects:

File size
Visual quality
Transparency support
Animation support
Browser compatibility
Sharpness on different screens
Loading time

Using the wrong format does not always break the page, but it often wastes data. For example, saving a simple logo as a large JPG may make the edges blurry. Saving a large photo as PNG may create a much heavier file than needed. Using WebP for photos and graphics can often reduce file size while keeping the image looking clean.

JPG: Best for Photos and Real-Life Images

JPG, also written as JPEG, is one of the most common image formats on the web. It works well for photographs, product images, backgrounds, travel pictures, food photos, and other images with many colors and soft details.

JPG uses lossy compression. That means it reduces file size by removing some image data. When done carefully, the difference is hard to notice. But if the image is compressed too much, it can look blurry, noisy, or blocky.

JPG is a good choice for:

Photos
Blog images
Product photos
Large background images
Real-world pictures with many colors

JPG is not the best choice for:

Logos
Icons
Text-heavy images
Screenshots with sharp edges
Images that need transparency

A common mistake is uploading a huge JPG directly from a camera or design tool. These images can be several megabytes. Before using them on a website, resize them to the actual display size and compress them properly.

PNG: Best for Transparency and Sharp Graphics

PNG is another popular format. It is often used for graphics that need clean edges or transparent backgrounds. Unlike JPG, PNG can preserve sharp lines and text very well. It also supports transparency, which makes it useful for logos, icons, stickers, UI elements, and images placed over colored backgrounds.

PNG usually creates larger files than JPG when used for photos. That is why PNG should not be your default choice for every image.

PNG is a good choice for:

Logos
Icons
Screenshots
Transparent images
Simple graphics
Images with text
UI elements

PNG is not ideal for:

Large photos
Full-width hero images
Photo galleries
Blog images with real-life scenes

For example, if you have a screenshot of a software interface, PNG may keep the text sharp. But if you have a photo of a beach, JPG or WebP will usually be better.

WebP: A Strong Default for Modern Websites

WebP is one of the best image formats for modern web performance. It can handle both photos and graphics, supports transparency, and usually produces smaller files than JPG or PNG.

This makes WebP very useful for websites that want fast loading without losing too much visual quality. Many images that were once uploaded as JPG or PNG can be converted to WebP to reduce page weight.

WebP is useful for:

Blog images
Thumbnails
Product images
Hero images
Transparent graphics
Website banners
Image-heavy pages

For many websites, WebP is a smart default format. You can keep original JPG or PNG files for editing and storage, then use WebP versions on the live website. If you already have JPG or PNG images, you can use a simple tool to convert JPG or PNG to WebP before uploading them to your site.

That small step can make a page feel faster, especially when there are many images.

SVG: Best for Logos, Icons, and Simple Illustrations

SVG is different from JPG, PNG, and WebP. It is a vector format. Instead of storing image pixels, it stores shapes, paths, and instructions. This means SVG can scale to any size without becoming blurry.

SVG is excellent for simple graphics. It is often the best choice for logos, icons, arrows, line illustrations, badges, and interface graphics.

SVG is good for:

Logos
Icons
Simple illustrations
Decorative shapes
UI graphics
Graphics that need to stay sharp at all sizes

SVG is not the best choice for:

Photos
Complex artwork with many colors
Large detailed images
Images from cameras

One big advantage of SVG is that it often stays very small in file size for simple designs. A logo that looks blurry as JPG may look perfectly sharp as SVG.

However, SVG should be used carefully. Since SVG files can contain code-like data, only upload SVGs from trusted sources or sanitize them before using them on a public website.

AVIF: Very Small Files, But Use Carefully

AVIF is a newer image format that can produce very small files with good quality. It can be excellent for web performance, especially for photos and large visual images.

In many cases, AVIF can be smaller than WebP. But it is not always the easiest format to use. Encoding can take longer, some workflows do not support it smoothly, and older systems may have issues with it.

AVIF is good for:

Large photos
Hero images
High-performance websites
Image-heavy pages
Sites with a modern optimization workflow

AVIF may not be ideal when:

You need the simplest workflow
Your CMS does not handle it well
You want easy editing and broad tool support
You do not have fallback images

A good approach is to use AVIF where it gives a clear size benefit, but still keep WebP or JPG fallback options when needed.

GIF: Use Only When Necessary

GIF is well known for simple animations. But for modern websites, GIF is often not the best choice. Animated GIF files can become very large, especially when they contain many frames or colors.

For short animations, it is often better to use video formats or animated WebP where supported. GIF is still useful in some cases, but it should not be used for large animations on performance-focused pages.

GIF is okay for:

Very small simple animations
Tiny decorative motion
Basic legacy support

Avoid GIF for:

Long animations
Large screen recordings
Product demos
Hero section animations
Anything that behaves like a video

A large GIF can slow down a page more than people expect.

Quick Rule: Which Format Should You Use?

Here is a simple way to choose. If you want a deeper technical explanation of different image types, the MDN guide to image file formats is also a useful reference.

Use JPG when the image is a normal photo and you need broad compatibility.

Use PNG when the image needs transparency, sharp text, or clean edges.

Use WebP when you want smaller files for photos, graphics, thumbnails, and general website images.

Use SVG for logos, icons, and simple scalable illustrations.

Use AVIF when you want very small image files and your website setup supports modern image delivery.

Use GIF only for small simple animations, not large motion content.

For most modern websites, the practical answer is simple: use SVG for logos and icons, WebP for most normal images, and JPG or PNG only when they are specifically needed.

Image Format Is Only One Part of Optimization

Choosing the right format helps a lot, but it is not the only thing that matters. A WebP image can still be too large if its dimensions are huge. A JPG can still load fast if it is properly resized and compressed.

Before uploading images, check these things:

1. Resize Images Before Uploading

Do not upload a 4000px wide image if your page only displays it at 800px. The browser may visually shrink it, but users still have to download the larger file.

Resize the image close to the size it will actually appear on the page.

2. Compress Without Destroying Quality

Compression reduces file size. But too much compression makes images look bad. The goal is not to make every file tiny at any cost. The goal is to find the balance between size and quality.

A good image should look clean while being light enough to load quickly.

3. Use Responsive Images

Different devices need different image sizes. A desktop screen may need a large image, while a mobile phone may need a smaller one. Responsive image techniques allow the browser to choose the right file size for the user’s screen.

This avoids sending desktop-sized images to mobile users.

4. Lazy Load Images Below the Fold

Images that are not visible immediately do not always need to load right away. Lazy loading lets the browser load below-the-fold images later, when the user scrolls near them.

This improves the first loading experience.

5. Reserve Image Space to Avoid Layout Shift

When images load late without reserved space, the page can jump. This creates a poor user experience and may affect Core Web Vitals. Always define image width and height, or use CSS aspect ratios, so the browser knows how much space to reserve.

Common Mistakes to Avoid

Many websites lose performance because of simple image mistakes.

One common mistake is using PNG for every image. PNG is great for some graphics, but it can be very heavy for photos.

Another mistake is uploading images straight from a phone or camera. These files are often much larger than needed for a webpage.

A third mistake is using one large image for all devices. Mobile users should not have to download the same large image used for desktop screens.

Another issue is ignoring transparency. If an image does not need transparency, PNG may not be necessary. If it does need transparency, JPG will not work properly.

Some websites also use too many decorative images. Even optimized images add weight. Every image should have a purpose.

Best Format Choices for Different Website Areas

For a logo, use SVG when possible. If SVG is not available, use PNG with transparency.

For a blog featured image, use WebP or JPG. WebP is usually better for performance.

For a product image, use WebP for the live website, while keeping the original high-quality file separately.

For a screenshot, use PNG if the text needs to stay sharp. WebP can also work well if the result remains clear.

For a hero image, use WebP or AVIF with responsive sizes. Keep the file as light as possible because hero images often affect the first view of the page.

For icons, use SVG. It stays sharp and usually loads fast.

For animated content, avoid large GIFs. Use video or a modern animated format when possible.

A Practical Workflow for Website Images

A simple workflow can prevent most image problems:

Start with the original high-quality image. Keep that original file safe for editing.

Resize the image to the size needed for the website.

Choose the correct format. Use SVG for icons and logos. Use WebP for most web images. Use PNG only when sharpness or transparency is needed. Use JPG when you need a simple photo format.

Compress the image.

Check how it looks on desktop and mobile.

Upload it to your site.

Test the page speed.

This process may sound small, but it can make a big difference across a full website.

Final Thoughts

The right image format can make a website faster without making it look worse. JPG, PNG, WebP, SVG, AVIF, and GIF all have their place, but they should not be used randomly.

For modern web performance, WebP is often the best everyday choice for photos, thumbnails, banners, and general website images. SVG is best for logos and icons. PNG should be saved for transparency and sharp graphics. JPG still works well for photos, but it is no longer the only practical option. AVIF can be excellent for advanced optimization, while GIF should be used carefully because animated files can become heavy.

Good image optimization is not about using the newest format everywhere. It is about choosing the format that fits the image, the page, and the user’s device.

When images are properly resized, compressed, and saved in the right format, your website loads faster, feels smoother, and gives users a better experience from the first click.

DEV Community: MD Zoheb

Beyond 'eval()': How I Built a Step-by-Step Math Calculator That Explains Its Work with AI

Why eval() is not enough

Hard-coding every possible solution gets messy

Where AI fits

I ask for structured output

Why I use LaTeX

AI gives me LaTeX. MathJax makes it readable.

I tell the model exactly how to format math

JSON escaping matters with LaTeX

Loading MathJax

Dynamic AI output needs another MathJax step

I keep text and equations separate

I do not ask the AI to generate HTML

The browser should not contain the AI API key

AI still needs verification

A hybrid system makes more sense

Word problems show where AI helps

Users do not always type clean math

Invalid problems need a clear error path

Public AI tools also need limits

The interface still matters

A live version

The architecture I would use again

The part I underestimated

How to Choose the Right Image Format for Web Performance

Why Image Format Matters for Website Speed

JPG: Best for Photos and Real-Life Images

PNG: Best for Transparency and Sharp Graphics

WebP: A Strong Default for Modern Websites

SVG: Best for Logos, Icons, and Simple Illustrations

AVIF: Very Small Files, But Use Carefully

GIF: Use Only When Necessary

Quick Rule: Which Format Should You Use?

Image Format Is Only One Part of Optimization

1. Resize Images Before Uploading

2. Compress Without Destroying Quality

3. Use Responsive Images

4. Lazy Load Images Below the Fold

5. Reserve Image Space to Avoid Layout Shift

Common Mistakes to Avoid

Best Format Choices for Different Website Areas

A Practical Workflow for Website Images

Final Thoughts

Why `eval()` is not enough