IMTools

    Tool Methodology

    Last updated: June 2026

    This page explains how every tool on IMTools is built and tested. Our goal is to be transparent about what runs in your browser and why you can trust the output.

    1. Client-side by design

    Every tool on IMTools runs entirely in your browser. We deliberately chose a client-side architecture because it gives users three guarantees we believe matter:

    • Privacy: your files never reach a server.
    • Speed: there is no network round-trip on the processing path.
    • Reliability: tools keep working even if our servers go down.

    2. Libraries we use

    • Images: HTML5 Canvas, browser-image-compression, libheif-js (HEIC).
    • PDFs: pdf-lib for editing, pdfjs-dist for parsing.
    • Word documents: mammoth for DOCX → HTML/text, docx for DOCX generation.
    • Spreadsheets: xlsx (SheetJS) for Excel and CSV.
    • OCR: tesseract.js with English plus several Indian language packs.
    • Cryptography: the native Web Crypto API for hash generation.
    • QR codes: qrcode.

    3. Quality and accuracy testing

    1. Each tool has a set of canonical input files (image, PDF, DOCX, CSV) used as regression fixtures.
    2. After every dependency upgrade we re-run those fixtures and compare the outputs to a reference.
    3. For compressors and converters that target a numeric budget (KB, dimensions), we verify the output falls within the documented tolerance.
    4. OCR and PDF-to-DOCX outputs are spot-checked for layout fidelity on real Indian government forms.

    4. Performance budget

    We aim to keep every tool page under 200 KB of JavaScript on first load. Heavy libraries (pdf-lib, tesseract.js, libheif) are dynamically imported only when you actually click "Convert" or "Process" so the page stays light.

    5. Accessibility

    Tools are built with semantic HTML, keyboard-accessible controls, proper labels and visible focus states. We test against WCAG 2.1 AA where applicable.

    6. Security

    Inputs that may contain HTML (Markdown editor, Meta Tag generator) are sanitized with DOMPurify before rendering. We never use eval, innerHTML with untrusted strings, or third-party scripts on processing paths.

    7. Limitations we are honest about

    • PDF-to-DOCX cannot perfectly reconstruct complex multi-column layouts because the formats are fundamentally different.
    • OCR accuracy depends on scan quality; very low-resolution scans (under 200 DPI) will return partial text.
    • Image compressors trade a small amount of quality for big size reductions; for archival or print use, keep the original.

    8. Feedback

    If a tool produces an unexpected result, please tell us with the input file and what you expected. We treat every report as a fixture for our regression suite.