DEV Community: Sambhav Tawar

How I Build a Screenshot text Editor

Sambhav Tawar — Sat, 27 Jun 2026 10:49:20 +0000

I can't count how many times I've been writing documentation, preparing a tutorial, or submitting a bug report and found myself staring at a screenshot that needed a small fix. A typo in the UI mockup. An API key that has to be blurred, an arrow pointing to the one button nobody seems to notice. Simple things, yet somehow always a hassle.

The tools I had were either too much or too little. Desktop apps like Photoshop gave me endless layers and filters I didn't need—I just wanted to swap a few words. Free online tools? They came with watermarks, forced sign-ups, or asked me to upload sensitive images to some unknown server. And not a single one of them could do the thing I genuinely craved: replace text inside a screenshot and have it look exactly like the original.

The space nobody was filling

Screenshot tools live in a strange, fragmented world. On one side you have heavyweight desktop apps like Snagit and Photoshop powerful, but expensive, install-heavy, and overkill for a quick edit. On the other side, lightweight capture tools like Lightshot or Greenshot let you annotate while you capture, but the moment you save and close, that annotation is baked in. No way to tweak it later.

Then there’s the web-based middle ground. Most of these tools fall into two camps: simple annotators (arrows, text boxes, cropping) or full-blown photo editors that sort-of-handle screenshots. Neither addresses the specific, frustrating problem of editing existing text inside a screenshot with real visual fidelity.

That’s exactly where Screenshot Editor Online lives. It’s not a general-purpose photo editor. It’s not yet another capture tool. It’s a screenshot text editor built for that moment when you already have a screenshot, you need to change the words, and you need the result to look seamless.

What it actually does

Replace text, keep the look

This is the whole reason the tool exists. You upload a screenshot. The tool uses OCR to find every text element. Click on a word or phrase, and it analyzes the pixels in that area to estimate the font family, size, color, weight, and style (bold, italic, serif or sans-serif). You type your new text, and it renders with those same properties.

Some examples:
Before:
After:

All the annotation tools you expect

Beyond the text magic, there’s a full annotation toolkit. You can draw arrows and shapes, add highlights, blur or pixelate sensitive stuff (emails, phone numbers, API keys), crop, resize, and scribble with a freehand pen. Everything you need to make a screenshot communicate clearly without leaving the browser.

No friction No catch

There’s no account to create, no watermark slapped on the output, no artificial edit limits. You drag your image in, do your work, and download the result. It handles PNG, JPG, WEBP, and BMP.

Privacy by default

Everything happens locally in your browser. Your image never leaves your machine. For developers working with internal mockups or customer data, that’s not a luxury it’s a necessity.

Under the hood

The stack

Three core technologies make this possible:

Fabric.js – gives me an object model on top of the HTML5 canvas, so I can treat shapes, text, and images as moveable, editable objects without losing my mind.

Tesseract.js – a browser-based port of the Tesseract OCR engine. It handles text detection entirely client-side, so there’s no need for a server.

Vanilla JavaScript – no frameworks, no dependencies beyond what’s essential. Plain HTML, CSS, and JS keep things fast and the bundle tiny.

The really tough bit: matching fonts

Tesseract.js tells me where text lives and what it thinks it says, but it doesn’t whisper a word about the font. I had to build custom logic that:
Upscales the image 3x before OCR – a simple trick that dramatically improves recognition of small text.
Uses page segmentation mode 11 (sparse text) to pick up words even in complex, non-linear layouts.
Filters out low-confidence detections – anything below 15% confidence gets tossed so you’re not editing nonsense.
Analyzes the pixels inside each text bounding box to estimate visual traits: stroke width (bold), slant (italic), and whether the font has serifs.
Pulls the dominant color straight from the text region for perfect color matching.

The trade-offs of local OCR

Keeping everything in the browser is a privacy win, but it’s not free. Tesseract.js is slower than a cloud service, and its accuracy isn’t quite as high. The 3x upscale helps a lot, but it adds processing time. For clean, readable UI screenshots—the vast majority of real-world use cases—the results are solid and fast enough.

Why build this now?

The technical pieces have been around for years. Tesseract.js has been available since 2018. Fabric.js even longer. So why hasn’t this tool existed before?

Two reasons. First, combining robust in-browser OCR with on-the-fly font matching is surprisingly tricky—most developers naturally reach for a server to do the heavy lifting. Second, the established players have been desktop apps or subscription-based SaaS products. The idea of a free, browser-first tool that obsesses over text replacement as the primary feature simply hadn’t found its champion yet.

What I learned along the way

OCR isn’t magic, Tesseract.js does a great job on clean, high-contrast text, but stylized fonts, low-res images, and messy backgrounds still trip it up. Upscaling helps, but it’s not a cure-all.

Font estimation is guesswork dressed in math. You can spot bold or italic from pixels. You cannot reliably distinguish Arial from Helvetica from Open Sans without a much larger contextual model. So, I focused on what matters: reproducing the visual weight, size, color, and slant. The exact font name is a nice-to-have; the visual match is a must.

Perceived performance matters, OCR on a chunky image can take several seconds. If users don’t see that something is happening, they assume the tool is broken. Keeping the UI responsive and communicative during processing was non-negotiable.

Where it fits in the market

Screenshot Editor Online isn’t trying to replace Snagit or CleanShot X—those are paid desktop tools with broader feature sets. It’s not competing with Canva or Fotor either; those are general-purpose design platforms.

Its real neighbors are other free web-based screenshot editors. But those tools are either annotation-only (no text editing), marred by watermarks, or require uploading your image to a server you know nothing about.

Our differentiators are clear and intentionally simple:

Text replacement with font matching – no other free tool does this.

Fully client-side – your image stays yours.

No watermarks, no caps – free means free.

No account needed – zero friction from the second you land on the page.

The people who care most? Developers, designers, technical writers, support engineers—anyone who lives in a world of screenshots and needs them to be right.

What’s coming next

The tool is live and starting to find its audience. There’s plenty left to do:

Sharper font detection – I’m continuing to refine how I estimate style, especially for tricky typefaces.

More export options – custom resolutions, additional formats.

Keyboard shortcuts – because power users deserve speed.

Batch processing – edit multiple screenshots in one session without starting from scratch.

Wrapping up

Screenshot Editor Online started the way a lot of side projects do: I was frustrated, and the thing I needed didn’t exist. Building it taught me a ton about OCR, canvas manipulation, and the quiet complexity of making something feel simple.

It’s free, it’s open-source, and it solves a real, everyday headache. If you’ve ever spent twenty minutes in Photoshop trying to match a font in a screenshot, you already know exactly why it’s here.

Give it a try at screenshoteditoronline.com. No account, no watermark, no limits. Just upload, edit, and download.

I Built a Subway Nutrition Calculator

Sambhav Tawar — Sat, 04 Apr 2026 09:16:17 +0000

A few months ago, I got tired of clicking through Subway’s website to figure out what I was actually eating. Their PDFs are fine if you want to look up one thing. But if you want to build a custom sandwich—add this bread, skip that cheese, double the chicken, then see how it fits into your daily calories good luck.

So, I built this calorie calculator.

Not a fancy app with a backend. Just a single HTML file with a ton of JavaScript, a massive JSON‑like data structure, and a stubborn refusal to let a bad UI ruin my lunch.

I’m going to walk you through how I built it, what broke along the way, and what I’d do differently next time.

The Problem

You’d have to manually add bread calories + meat calories + veggie calories (most are zero, but olives and avocado aren’t) + sauce calories. Then double it for footlong. Then remember that cheese adds fat and sodium. Then realize you forgot the salt and pepper.

It’s tedious and error‑prone. And it’s exactly the kind of problem a simple web tool can solve.

Step 1: Collecting the Data

I needed a complete, consistent dataset. Every bread, every protein, every cheese, vegetable, condiment, seasoning, side, soup, dessert, and pre‑made sandwich. Plus, salads, wraps, protein pockets, and No Bready Bowls.

I started with Subway’s official US nutrition PDF (2026 version). Then I cross‑referenced with their online menu, third‑party aggregators, and even some store‑level ingredient sheets.

Total items ended up at around 300+.
Here’s the rough breakdown:

Breads: 12
Pre‑made sandwiches: 30+
Proteins (a la carte): 20+
Cheeses: 5
Vegetables: 15
Condiments: 25+ (each with Normal and Light versions)
Seasonings: 3
Sides: 2
Salads: 25+
Wraps: 25+
No Bready Bowls: 25+
Protein Pockets: 4
Soups: 3
Desserts: 7
Sidekicks: 8 Each item needed the same set of nutrition fields:

Calories, total fat, saturated fat, trans fat, cholesterol, sodium, Total carbs, dietary fiber, sugars, added sugars, Protein, Vitamin A (mcg), Vitamin C (mg), Calcium (mg), Iron (mg).

I also tracked serving size in grams where available, though that’s mostly for reference.

What I learned: Never trust a single source. Cross‑reference everything and if you’re building a public tool, be transparent about where the data comes from and what’s estimated.

Step 2: Structuring the Data – The JavaScript Object That Runs Everything

I built one massive JavaScript object called subwayMenu. It has arrays for each category: breads, proteins, cheeses, vegetables, condiments, etc.

Here’s what a single bread item looks like:

javascript
{
    id: 'artisan-italian-bread-6inch',
    name: '6" Artisan Italian Bread',
    servingSize_g: 71,
    calories: 210,
    totalFat: 2,
    saturatedFat: 1,
    transFat: 0,
    cholesterol: 0,
    sodium: 380,
    totalCarbs: 39,
    dietaryFiber: 1,
    sugars: 3,
    addedSugars: 2,
    protein: 8,
    vitaminA_mcg: 0,
    vitaminC_mg: 0,
    calcium_mg: 1040,
    iron_mg: 16.2,
    category: 'bread'
}

Every item follows the same structure. That’s critical because later I loop through these objects to calculate totals, display values, and filter by search.

The size multiplier logic:
For sandwiches, users can choose 6‑inch or footlong. The calculator multiplies bread, proteins, cheeses, vegetables, condiments, and seasonings by 2 when footlong is selected. Pre‑made sandwiches, salads, wraps, and bowls are already sized – they don’t get multiplied again. That logic lives in the calculateTotalNutrition function, where I check a sizeAffected flag for each category.

The quantity system:
Users can add multiple of the same item (e.g., double meat, extra cheese). I store quantities in a separate currentSelection object. For each category, it’s a dictionary mapping item IDs to integers. Zero means not selected.`

javascript let currentSelection = { sandwichSize: '6inch', bread: null, proteins: {}, cheeses: {}, vegetables: {}, condiments: {}, // ... etc };
This structure makes it easy to add, remove, or adjust quantities without rebuilding the whole UI from scratch.

Step 3: The UI – Dropdowns, Tabs, and a Whole Lot of Dynamic Rendering

I wanted the interface to be clean but powerful. No external libraries just plain HTML, CSS, and vanilla JavaScript.

The layout:

Left side: Builder with collapsible categories (Bread, Proteins, Cheeses, etc.) and a tab switcher for different menu types (Sandwich, Salads, Wraps, etc.)

Right side: Results section with a nutrition label, calorie progress bar, current selection list, and action buttons.

The tab system:
On mobile, tabs become a dropdown toggle. On desktop, they could have been buttons, but I kept the dropdown consistent across all devices to simplify CSS. The active tab determines which set of categories (sandwich builder vs. pre‑made salads vs. wraps) is visible.

Collapsible categories:
Each category (e.g., “Proteins”) is a

with a header that toggles the content. I used a simple onclick handler (subwayToggleDropdown) that adds/removes an expanded class and rotates an SVG arrow.

Search inside categories:
Every category has a search input that filters items client‑side. No backend calls. The subwaySearchCategory function reads the input, filters the items array, and calls populateCategory to re‑render only that section.

The item list:
Each item is rendered as a row with a checkbox (or radio for bread), name, calories, and quantity controls (plus/minus buttons). The quantity buttons call subwayAdjustQuantity, which updates the currentSelection object and re‑renders the category and the current selection list.

Why re‑render instead of DOM manipulation?
Because it’s simpler, I rebuild the category HTML every time something changes. For a category with 20 items, that’s fine. For the whole page, I’d need to be more careful. But here, re‑rendering is fast enough that users don’t notice a delay.

Step 4: The Nutrition Calculation

The calculateTotalNutrition function is the heart of the tool.

It does four things:

Initializes a totals object with zeros for every nutrition field.

Applies the size multiplier (2 for footlong) to categories that scale with sandwich size.

Loops through every selected category – bread, proteins, cheeses, vegetables, condiments, etc. And adds the item’s nutrition multiplied by quantity and multiplier.

Returns the final totals and a list of ingredients (for the ingredients section).

The math is straightforward addition. No fancy rounding until the end, where I round to one decimal place to keep the display clean.

The tricky part:
Some items have tiny values (e.g., 0.5g fiber). When you multiply by quantity and size, you get fractions. I store everything as numbers and only round when displaying. That keeps internal calculations accurate.

The FDA daily values:
I hardcoded a fdaDailyValues object based on a 2,000‑calorie diet. The nutrition label shows % Daily Value for each nutrient. I calculate that as (nutrient_value / fda_daily_value) * 100. For vitamins and minerals, I use the actual mcg/mg values and compare against the FDA standards.

Step 5: The Current Selection Panel

One thing I’ve always hated about other calculators: you add items, but you can’t see what you’ve added without scrolling back up.

So, I added a “Current Selection” panel on the right side (bottom in mobile). It lists every item you’ve chosen, with quantity and calories. And here’s the kicker: each item has a small “X” button that removes it directly from the selection.

That removal calls subwayRemoveItemFromSelection, which updates the currentSelection object, then re‑renders the affected category (to uncheck the item) and the selection panel itself.

It’s a small quality‑of‑life feature, but it makes a huge difference when you’re tweaking a meal.

Step 6: The Save Function

I added a “Save Nutrition Data” button that exports everything as a plain text file.

The subwaySaveNutritionInfo function:

Calls calculateTotalNutrition to get current totals and ingredients.

Builds a formatted string with meal details, ingredients, nutrition facts, and daily progress.

Creates a Blob, generates a download link, and triggers a download.

Shows a temporary “Saved!” feedback on the button.

I chose plain text because it’s simple, works everywhere, and users can paste it into a note or spreadsheet. No external dependencies.

What Broke (And How I Fixed It)

1. The bread radio group:
Originally, I used radio buttons (only one bread allowed). But dynamically re‑rendering radios with JavaScript and keeping their state was a nightmare. I switched to checkboxes but enforced “only one” in the selection logic. The UI still looks like radios, but under the hood, it’s a checkbox group with manual deselection.

2. The footlong multiplier:
At first, I applied the multiplier to everything including pre‑made salads and wraps. That was wrong, Salads and wraps have their own fixed nutrition. I had to add a sizeAffected flag to each category and only multiply bread, proteins, cheeses, vegetables, condiments, and seasonings.

3. Search resetting on item change:
Every time a user added or removed an item, the category would re‑render and lose the search term. I fixed that by storing the search term in a variable and re‑applying it after re‑render. The subwaySearchCategory function now caches the filtered results.

4. The save button not working in some browsers:
Some browsers block programmatic clicks on download links. I switched to using a Blob and URL.createObjectURL, which works everywhere. Also added a fallback alert if something fails.

The Bottom Line

Building this calculator was a lesson in data wrangling, UI design for real‑world users, and the joy of solving your own problem.

It’s not perfect and the code is a little messy. The data could be more complete, but it works. You can build a custom Subway meal, see exactly what you’re eating, and save it for later.

If you’re a developer thinking about building a similar tool for another restaurant chain, here’s my advice:

Start with the data: Clean, consistent data is 80% of the work.

Build the logic first then the UI: Get the calculation engine working in the console before you worry about buttons.

Test with real users: I handed this to a few friends and watched where they got confused. That’s how I learned about the footlong multiplier bug.

Don’t overcomplicate it: You don’t need a backend, a database, or a build system. A single HTML file with inline CSS and JS is fine for a tool like this.

Now, whenever I walk into Subway, I know exactly what I’m ordering. And if I’m not sure, I open this calculator on my phone and build it before I get to the counter.

That’s the whole point, tools should make your life easier, not harder.

I hope this walkthrough helps someone else build something useful. And if you just wanted to use the calculator, well, now you know what’s under the hood.

Building a Multi-Scale CGPA Calculator

Sambhav Tawar — Mon, 28 Jul 2025 05:57:42 +0000

As a developer passionate about creating tools that solve real-world problems, I recently built a comprehensive CGPA (Cumulative Grade Point Average) calculator. This project emerged from my own experience as a student struggling to calculate my academic performance accurately across different grading systems. In this article, I'll walk through the technical implementation, design decisions, and features of this open-source calculator.

The Problem Space
Academic grading systems vary significantly across institutions. While some universities use a 10-point scale, others use 4-point or 5-point systems. This creates confusion for students who need to:

Calculate their current semester GPA.
Track cumulative performance (CGPA).
Convert between different grading scales.
Understand how specific courses impact their overall average.

Technical Stack

The calculator is built with:

Frontend: Vanilla HTML, CSS, and JavaScript
Charts: Chart.js for data visualization
Icons: Font Awesome for UI elements
Analytics: Google Analytics for usage tracking (non-intrusive)
Hosting: Static site deployment

Key Features Implemented

1. Multi-Scale Support

const gradeOptionsByScale = {
  10: [ 
* grade options */ ],
  4: [ /* grade options */ ],
  5: [ /* grade options */ ]
};

The calculator dynamically adjusts its interface based on the selected grading scale (4.0, 5.0, or 10.0), ensuring accurate calculations regardless of the institution's system.

2. College-Specific Presets

const colleges = [
  { name: "Delhi University", scale: 10, location: "Delhi" },
  { name: "Ashoka University", scale: 4, location: "Sonipat" },
  // 15+ other institutions
];

By selecting their college, students get automatically configured with the correct grading scale and grade descriptors.

3. Dynamic Course Management

function createCourseCard(index, scale) {
  // Dynamically generates course input fields
}

function addCourse() {
  // Adds new course fields on demand
}

The interface allows students to add or remove courses as needed, with real-time validation and course count tracking.

4. Visual Data Representation

function createGaugeChart(ctx, value, maxScale, title) {
  return new Chart(ctx, {
    type: 'doughnut',
    // Chart configuration
  });
}

Using Chart.js, the calculator displays results through intuitive doughnut charts that visually represent academic performance.

5. Calculation Transparency

function showCalculationBreakdown() {
  // Generates detailed HTML table showing the math
}

A comprehensive breakdown section shows students exactly how their GPA was calculated, building trust through transparency.

6. Responsive Design

@media (max-width: 768px) {
  /* Mobile-specific styles */
  .course-grid {
    grid-template-columns: 1fr;
  }
}

The calculator works seamlessly on all devices using CSS Grid, Flexbox, and responsive design principles.

Technical Challenges and Solutions

Challenge 1: Dynamic Form Generation

Generating course inputs dynamically while maintaining state was tricky. I solved this by:

Creating a template-based card generation system
Using event delegation for efficient handling
Storing state in DOM elements with data attributes

Challenge 2: Cross-Scale Calculations

function calculateCGPA() {
  // Handles different scales and conversions
  const currentScale = parseInt(cgpaScale.value) || 10;
  // Calculation logic
}

The algorithm needed to handle:
Different grading scales
Previous CGPA integration
Credit-weighted calculations

The solution was a flexible calculation function that normalizes all inputs to a common base.

Challenge 3: Responsive Data Tables

.table-responsive {
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
}

For the detailed breakdown tables, I implemented horizontal scrolling containers that work smoothly on mobile devices while maintaining readability.

Challenge 4: Performance Optimization
To ensure smooth performance:

Chart instances are properly destroyed before recreation
DOM operations are minimized through batch updates
Event listeners are delegated where possible

User Experience Considerations

Progressive Disclosure: Advanced options (previous CGPA) are available but don't clutter the main interface.

Visual Feedback: Animations and color-coded results help users understand their performance at a glance.

Educational Content: Integrated articles explain grading systems to help students understand the calculations.

Error Prevention: Real-time validation prevents invalid inputs and provides helpful messages.

project/
├── index.html
├── style.css
└── script.js

The application follows a simple yet effective structure:

HTML: Semantic markup with proper ARIA attributes.
CSS: Modular design with CSS variables for theming. 3.JavaScript: Modular functions with clear separation of concerns.

Building this CGPA calculator was a rewarding experience that combined technical challenges with practical utility. The project demonstrates how vanilla web technologies can create powerful, accessible tools without heavy frameworks.

The complete tool is available on our site for anyone who wants to examine and test the tool.