DEV Community: Enlh NG

Migrating legacy .doc/.xls/.ppt files: a runbook with acceptance tests (28 of 29 checks survived, plus one trap)

Enlh NG — Thu, 01 Oct 2026 05:45:07 +0000

Sooner or later someone hands you a shared drive full of .doc, .xls and .ppt files and says "move it all to the new formats". Converting one file is easy. Converting 4,000 and knowing nothing silently broke is a migration. This is the runbook I'd use, with the two scripts I tested: a pre-flight / batch / post-flight converter and a round-trip experiment that shows what a LibreOffice-based pipeline keeps and loses.

Step 0: know what "conversion" is in your pipeline

Most free converters (online or self-hosted) call LibreOffice in headless mode. One online converter I checked says so on its own page (conversion uses LibreOffice, so "the output may differ from the original in some details"). Whatever tool you pick, the fidelity of your migration is the fidelity of its engine, so test the engine on a sample of your own files.

Step 1: pre-flight, because the converter will say "success" on junk

Legacy binary Office files are OLE2 containers and begin with the bytes D0 CF 11 E0 A1 B1 1A E1. Modern files are ZIP packages and begin with PK. Plenty of ".xls" files in the wild are really HTML exports, and plenty of ".doc" files are plain text or already .docx. I tested what LibreOffice does with them:

a plain-text file named fake.doc → converted without complaint into a 4,994-byte fake.docx
an HTML file named web.xls → converted without complaint into a 5,536-byte web.xlsx

Both runs reported success. You can end up with a folder of "converted" files that were never Office documents. So check the magic bytes first:

OLE = bytes.fromhex('D0CF11E0A1B11AE1')
ZIP = b'PK\x03\x04'

def preflight(path):
    if os.path.getsize(path) == 0: return 'empty file'
    head = open(path, 'rb').read(8)
    if head.startswith(ZIP): return 'already a zip-based file (renamed .docx/.xlsx/.pptx?)'
    if head != OLE: return 'not an OLE2 file (renamed text/HTML/RTF?)'
    return None

One online converter's page says the same thing in its own words: it accepts "genuine binary DOC, XLS, and PPT files only" and rejects renamed text files. My pre-flight is deliberately strict; HTML-as-.xls exports are a legitimate case, but they deserve a separate, reviewed path, not the same batch.

Step 2: convert with a private profile and a timeout

def convert(src, outdir, ext, timeout=90):
    profile = tempfile.mkdtemp()      # own profile: no lock collisions between runs
    try:
        r = subprocess.run(['soffice', f'-env:UserInstallation=file://{profile}', '--headless',
                            '--convert-to', TARGET[ext], '--outdir', outdir, src],
                           capture_output=True, text=True, timeout=timeout)
        return r.returncode, r.stderr.strip()[:120]
    except subprocess.TimeoutExpired:
        return -1, f'timeout after {timeout}s'
    finally:
        shutil.rmtree(profile, ignore_errors=True)

A separate -env:UserInstallation per call avoids the stale-lock problems you meet when one headless instance is already running; the timeout makes one bad file unable to hang the whole job.

Step 3: post-flight, because exit code 0 is not proof

The output must exist, be a valid ZIP and contain [Content_Types].xml:

def postflight(out):
    if not os.path.exists(out): return 'no output file'
    try:
        z = zipfile.ZipFile(out)
        if z.testzip() is not None: return 'corrupt zip'
        if '[Content_Types].xml' not in z.namelist(): return 'not an OOXML package'
    except zipfile.BadZipFile:
        return 'not a zip'

I ran the full script (in the package) on a folder with 3 genuine legacy files and 4 bad ones. Result: the 3 real files were OK (0.2–0.4 s each), and the empty file, the text file, the HTML file and the renamed .docx were all SKIPPED with a reason, written to report.csv.

Step 4: acceptance tests: what does a conversion keep?

I did not want to guess, so I built a fixture per format with known features, converted it to the legacy format and back to the modern one (LibreOffice 24.2), and read each property back with openpyxl, python-docx and python-pptx:

Highlights:

Excel: all 20 formulas, three number formats, merged cells, a comment, conditional formatting, data validation, a defined name, column width, a chart, an image and a hidden sheet came back. Every cell value and formula text compared equal. Freeze panes did not (B2 became none).
Word: headings, table, image, header, footer, a bold run, a comment, a tracked insertion, a tracked deletion and a bullet list all survived.
PowerPoint: 3 slides, speaker notes, a picture, a chart and a table survived.

Two caveats matter more than the 28 greens:

My legacy files were written by LibreOffice, not by Microsoft Office. A round trip through the same engine is friendlier than converting a file that Office 2003 wrote. Treat this as a harness and a baseline, not a guarantee. The way to get a real answer is to run it on a sample of your own files.
I did not isolate whether the freeze panes were lost on the way to .xls or on the way back. A direct .xlsx → .xlsx pass through the same engine kept them (B2), so it is specific to the .xls leg in my setup.

The trap: converting back loses data silently

Legacy .xls has a hard limit of 65,536 rows per sheet. I wrote a 70,000-row .xlsx, converted it to .xls and back, and the sheet came back with 65,536 rows. No error. Nothing about it was in the script's output. If any step of your workflow goes through .xls (for a partner who "needs the old format"), add a row count to the acceptance test.

"Modern files are smaller": not always

A common claim is that the modern formats are much smaller. In my fixtures:

Format pair	Original modern	Legacy	Converted back
xlsx / xls	159,266 B	166,400 B	162,797 B
docx / doc	188,530 B	176,128 B	160,774 B
pptx / ppt	191,124 B	815,616 B	196,474 B

Only the PowerPoint pair showed a big gap, which comes from how .ppt stores embedded pictures, and my picture was incompressible noise, so treat the sizes as illustrative. Do not promise "50% smaller" to anyone before you have measured their files.

What an online converter says about itself

For a few files you do not need a script. For comparison, here is one converter page, from its own text (Nov 2026):

Option	Batch	Limits	Not preserved / caveats	Where it runs
The script above	any folder	your timeout	macros are not carried over by this pipeline; you decide on pre- and post-flight	your machine
ToolTiny Office Format Converter	up to 10 files, mixed types; several inputs return a ZIP	20 MB total; 90 s per file; 5 min per job; one failed file fails the whole batch	macros not retained; password-protected files unsupported; fonts, pagination, formulas, charts and presentation effects may differ	uploaded to its server, LibreOffice converts, temp files removed after download or failure

I did not re-check other converters for this post.

Checklist for your own migration

Pre-flight: size, magic bytes, passwords, macros (VBA is not converted; keep the originals).
Convert in an isolated profile with a timeout.
Post-flight: valid package, then your feature checks (formulas, row counts, headings, slide counts).
Spot-check by eye: 5% of files, the ugliest ones (fonts, pagination and animations are the usual drift; I did not test them).
Keep the originals until someone has opened the converted file.

Limits of this write-up

One engine (LibreOffice 24.2.7.2) and synthetic fixtures. Real files, especially ones saved by old Office versions, will find problems mine did not.
I did not test macros, passwords, fonts, page breaks, animations or transitions.
The converter row is what the vendor's page states, not a test of its output.

If your migration found a property that did not survive, tell me which one and I will add it to the acceptance test.

Same contract, seven variants: what should a Word diff flag, and what do three methods actually flag?

Enlh NG — Sun, 27 Sep 2026 15:46:25 +0000

"The client sent a final version, did anything change?" is a question a diff should answer. But "changed" is not one thing in a .docx. A file can differ in thousands of bytes and not at all in words, or differ in the one word that matters and leave the XML almost untouched. I built one small contract and seven variants of it, then ran three comparison methods and wrote down what each one flags. This is the lab notebook.

Setup

A synthetic services agreement: 12 body paragraphs, a 2×2 fee table, and a footer. Built with python-docx 1.2.0 on Python 3.13.
Seven variants, each compared to the original:
1. Re-saved: the same file converted docx → docx by LibreOffice headless (not Word), no edits.
2. Cosmetic: curly apostrophes, a non-breaking space, and a double space.
3. Real edit: "30 days" → "45 days".
4. Moved: one paragraph moved to the end.
5. Pending tracked change: "30" deleted and "45" inserted as real w:del / w:ins revisions.
6. Table: the fee cell changed.
7. Footer: only the footer text changed.
Three methods, all using difflib.SequenceMatcher and counting non-equal opcodes:
- A: raw lines of pretty-printed word/document.xml.
- B: text passages (non-empty paragraphs and table cells, in reading order), compared exactly.
- C: the same passages, normalized first (Unicode NFKC, curly quotes to straight, whitespace collapsed).

Results

Variant	Should flag	A: XML lines	B: passages	C: normalized
Re-saved, no edits	0	43	0	0
Cosmetic whitespace and quotes	0	3	3	0
Real edit (30 → 45)	1	1	1	1
Paragraph moved	2 (a removal and an addition)	2	2	2
Pending tracked change	1	1	1	1
Fee table cell	1	1	1	1
Footer only	1	0	0	0

What I learned from each row

Re-saving is noise for method A and invisible to B. The LibreOffice re-save produced a file of 21,769 bytes from the original's 37,562, and 43 changed XML lines, yet every body paragraph was word-for-word identical. If your "diff" looks at XML or bytes, a document that went through another editor looks heavily changed. Compare text, not markup. (This was LibreOffice, not Word; I did not test a Word re-save.)

Cosmetic differences need a normalizer. Smart quotes, a non-breaking space and a double space made three paragraphs "different" under exact text comparison. After normalization the count dropped to zero. The cost is that a normalizer can also hide a real change: if a contract's meaning depends on a double space, which is rare, you need the strict mode. That is why the better tools expose this as an option.

A moved paragraph is two changes, by design. A sequence diff has no "move" operation, so the paragraph is reported as removed in one place and added in another. That is a good reminder that "2 changes" can mean "1 paragraph went somewhere else".

Tracked changes can make a naive reader lose a number. In variant 5 the paragraph reads "within 45 days" once the revision is accepted. But python-docx's paragraph.text returned:

The Supplier shall deliver the Services within  days of the Effective Date.

The number vanished, because the inserted run lives under w:ins instead of directly under the paragraph and w:del text is stored as w:delText. My passage extractor walks all w:t descendants instead, which gives the accepted view:

def passages(path):
    d = docx.Document(path); out = []
    for ch in d.element.body.iterchildren():
        if ch.tag == qn('w:p'):
            t = ''.join(n.text or '' for n in ch.iter(qn('w:t')))   # includes w:ins text, skips w:delText
            if t.strip(): out.append(t)
        elif ch.tag == qn('w:tbl'):
            for tc in ch.iter(qn('w:tc')):
                t = ''.join(n.text or '' for n in tc.iter(qn('w:t')))
                if t.strip(): out.append(t)
    return out

Whichever way a tool treats pending revisions, you want to know it, because the same file can read as "30" or "45" depending on the tool. (A comparison page I checked says that for existing tracked changes, inserted text is included and deleted text is excluded, which is the accepted view.)

Scope is a decision. The footer row is zero for all three methods because the footer lives in a different part of the package. That is not a bug in difflib, it is a scope choice: my extractor only reads the body. Text boxes, footnotes, endnotes, comments and headers are separate parts too. Before trusting any "no differences found", look at the tool's list of what it does not compare.

The comparison functions

def norm(s):
    s = unicodedata.normalize('NFKC', s)
    s = s.replace('’', "'").replace('‘', "'").replace('“', '"').replace('”', '"')
    return re.sub(r'\s+', ' ', s).strip()

def nchanges(a, b):
    sm = difflib.SequenceMatcher(None, a, b, autojunk=False)
    return sum(1 for op in sm.get_opcodes() if op[0] != 'equal')

nchanges([norm(x) for x in passages('v0.docx')],
         [norm(x) for x in passages('v3_edit.docx')])   # 1

autojunk=False matters: with the default heuristic, difflib may treat frequent items as junk in long sequences and give odd matches.

Choosing a tool: the questions come from the table above

Option	Output	What is compared / not	Where it runs
This script (`difflib`)	whatever you print	body paragraphs and table cells (my choice)	your machine
ToolTiny Compare Word Documents	standalone HTML report (removed red, added green); not a Word tracked-changes file	non-empty body paragraphs and table-cell text; not fonts, images, numbering, headers, footers, text boxes, footnotes, endnotes or comments; moved text may show as a removal plus an addition; options to ignore whitespace and case	uploaded to its server and removed after the request; up to 20 MB per file, 200,000 characters and 2,000 passages
diff.tools	its page lists "tracked changes between two .docx"; output format not stated	not stated	page says processing is local in the browser, nothing uploaded; limits not stated
Draftable (free web tool)	side-by-side view and change list; PDF export; its page lists several redline types including Word redlines	Word, PDF, Excel, PowerPoint and text per its FAQ	not stated for the free tool; free-tier limits not stated on the page I read

Things I could not check: Microsoft's own Word "Compare" documentation did not load for me, so I make no claims about it. The old post's other two tools (FreeRedline, Jubarte) I did not re-verify, so they are not listed. All vendor statements are as read in Nov 2026.

Limits of this experiment

One synthetic document, built with python-docx. Real contracts have nested tables, fields, content controls, and styles that change text indirectly.
The re-save came from LibreOffice, not Word, and Word may produce different XML for the same text.
difflib is a line/sequence diff over passages. It does not show intra-paragraph word changes; tools that highlight "30 → 45" inside a sentence run a second, word-level pass.
I tested three methods of my own, not the vendors' algorithms. The tool table lists what each page says, not what I measured.

The checklist I took from it

Diff text, not bytes or XML.
Decide whether quotes, spaces and case count, and make that visible as an option.
Decide what happens to pending tracked changes, and read the tool's note on it.
Read the "not compared" list (headers, footers, text boxes, comments) before you say "nothing changed".
Treat "2 changes" for a moved block as one change in disguise.

If you have a document type that breaks these rules, send it over and I will add a row.

Top 10 ways merging and splitting Excel files goes wrong (each one reproduced)

Enlh NG — Thu, 24 Sep 2026 15:44:03 +0000

Most advice about merging Excel files is a list of tools. The failures people actually hit are not about the tool, they are about what a merge silently does to formulas, IDs, dates and formatting. So here is a top 10 of those failures. Each one comes from a small test I ran (openpyxl 3.1.5, pandas 3.0.5, LibreOffice for recalculation), and the full script is in the last section.

1. Rewriting through pandas keeps the values and nothing else

The most common "merge" script is pd.read_excel(...) then to_excel(...). I built a sheet with conditional formatting, a data-validation list, a comment, an image, a defined name, a custom column width and frozen panes, then copied it two ways:

openpyxl's load_workbook then save kept all seven. A pandas read-then-write kept none of them, and renamed the sheet to Sheet1. A chart also survived the openpyxl round trip in a separate test (I did not test the pandas path for charts). Things I did not test: pivot tables, slicers, shapes, form controls. Test your own file types before trusting a round trip.

2. A file nobody has opened in Excel has no formula results

I wrote a file with openpyxl containing =B2+C2, then read it:

pd.read_excel('f1.xlsx', sheet_name='Sales')['Total'].tolist()   # [nan, nan]
openpyxl.load_workbook('f1.xlsx', data_only=True)['Sales']['D2'].value  # None

openpyxl stores the formula but no result, so any reader that wants values gets nothing. After I opened and re-saved the file through LibreOffice headless (soffice --headless --convert-to xlsx), the same reads returned [30, 70] and 30. Files saved by Excel carry cached values; files generated by code often do not.

3. `data_only=True` plus `save()` deletes your formulas for good

wb = openpyxl.load_workbook('recalculated.xlsx', data_only=True)
wb.save('out.xlsx')
openpyxl.load_workbook('out.xlsx')['Sales']['D2'].value   # 30, not "=B2+C2"

data_only=True is a read mode. If you save that workbook, the formulas are replaced by their cached values. That is exactly what you want for a "values only" export and exactly what you do not want for a working file.

4. Formulas that point at a sheet the new workbook does not have

Merging by copying cells from one workbook into another carries the formula text along:

dst['A1'] = src['Summary']['A1'].value   # '=SUM(Sales!B2:C3)'
dst.sheetnames                           # ['Sheet'] — there is no 'Sales'

The text still names Sales, which no longer exists in the destination. The same thing happens when you split a workbook and one sheet's formulas refer to another. Also, copy_worksheet only works inside one workbook; across workbooks it raises ValueError: Cannot copy between worksheets from different workbooks. Decide per formula: keep the references (and keep the sheets together) or freeze to values.

5. Sheet names have rules, and some are enforced quietly

Duplicate names: creating a second sheet called Sales quietly gives you Sales1. When you merge ten files that each have Sheet1, you get Sheet11, Sheet12… unless you rename them yourself.
A / in a name raises ValueError: Invalid character / found in sheet title.
A 32-character title is accepted by openpyxl, with a warning that "some applications may not be able to read the file". Excel's own limit is 31 characters, so prefix names with the source file name and truncate.

Bonus: openpyxl will save a workbook under an .xlsm file name without the macro parts, and the file's workbook content type stays the plain .xlsx one. I did not open it in Excel; macros need keep_vba=True on load, and I did not test that path.

6. IDs with leading zeros become numbers

A text cell 00123 next to a numeric 456:

pd.read_excel('f5.xlsx')['id'].tolist()              # [123, 456]
pd.read_excel('f5.xlsx', dtype=str)['id'].tolist()   # ['00123', '456']

If the default read happens first and you then write a CSV, the zeros are gone for good (my round trip printed 123). Read ID columns as str.

7. Merged cells only keep one value

A vertical merge A2:A4 holding "Ops" reads like this:

pd.read_excel('f6.xlsx')['Dept'].tolist()          # ['Ops', nan, nan]
pd.read_excel('f6.xlsx')['Dept'].ffill().tolist()  # ['Ops', 'Ops', 'Ops']

Excel stores the value only in the top-left cell. ffill() is the fix for stacking, but it also fills genuine blanks, so apply it only to the merged column.

8. Stacking rows needs normalized headers

pd.concat([a, b]).columns   # ['Region', 'Sales', 'region ']

Region and region (lowercase, trailing space) are two different columns, so you get a third, half-empty one. Strip and lowercase headers before concat, and print the resulting columns before you trust the merge.

9. The sheet has a hard row limit

Writing row 1,048,577 raises ValueError: Row numbers must be between 1 and 1048576. Stacking ten large exports can cross that line, so check the total row count first and split the output into several sheets or files.

10. Two workbooks can use different date systems

The .xlsx format stores dates as serial numbers with a base date that can be 1900 or 1904 (a workbook setting). I wrote 2026-11-06 into a 1904-based workbook. The file holds the serial 44870; openpyxl reads it back correctly as 2026-11-06 because it honors the workbook's epoch. Read the same serial as a 1900-system date and you get 2022-11-05, which is 1,462 days off. Copy raw serials between workbooks that use different systems and every date moves by four years and a day. Compare wb.epoch before merging.

If you would rather not code

For one-off merges, a tool saves the script. The questions to ask a tool are the ten above: does it keep formatting, what does it do with formulas, how does it name sheets, and where does your file go? What I could check from the vendors' own pages in Nov 2026:

Option	Merge style	Formulas	Unsupported content	Where it runs
openpyxl script (above)	whatever you write	you choose (items 2–4)	pivots/shapes/slicers untested here	your machine
ToolTiny Merge & Split Excel	each source sheet becomes a tab (rows are not appended); split gives one XLSX per sheet in a ZIP	choice of "use last saved values" or "keep formulas"; the keep option does not support named ranges, structured table references, INDIRECT, OFFSET or external references	charts, images, shapes, pivots, external links: the file is refused, not silently dropped; XLSM unsupported	its server; up to 10 XLSX files and 20 MB per merge, 100 sheets and 250,000 cells per job; temp files removed after the download or a failure
Excel itself (Move or Copy sheet, Power Query "Combine")	tabs, or stacked rows with Power Query	native	native	your machine

I could not open Microsoft's documentation pages with my tooling, so I make no claims about Excel's own limits beyond what you can try in the app yourself. I did not re-verify other online mergers for this post.

The reproduction script

test_pitfalls.py builds every fixture above and prints the results shown here. It needs openpyxl, pandas and Pillow; item 2's cached-value check uses LibreOffice's soffice.

Limits

Versions: openpyxl 3.1.5, pandas 3.0.5, Python 3.13. Other versions may behave differently.
I did not open the outputs in desktop Excel, so claims about what Excel shows stay at the file level (what is stored), not what the Excel UI displays.
The fixtures are small and synthetic; real workbooks have more ways to break.
Vendor statements are as read in Nov 2026.

What is the ugliest merge failure you have seen? I would add it as number 11.

A free AI background remover is three questions: which model, which license, where do the pixels go

Enlh NG — Tue, 22 Sep 2026 08:52:24 +0000

I wrote a comparison of free background removers a while ago and praised one tool for naming its model. A name is checkable, I said. Then I did the checking I had skipped: I read the model card, and I measured what a page sends. This post is that audit, with a script you can reuse.

"Free" and "AI" tell you almost nothing. Three questions do:

Which model runs, and what is its license?
Where do the pixels go?
Will the service still exist next month?

1. Which model, and under what license

Many "AI" background removers are a thin page around an open-weight model. The weights have their own license, separate from any code around them. From the model cards and repositories, read in Nov 2026:

Model / package	Stated license	Size / base (as stated)	Commercial use
BRIA RMBG-1.4	`bria-rmbg-1.4`, "source-available model for non-commercial use"	44.1M parameters; "developed on the IS-Net"; input resized to 1024×1024	"subject to a commercial agreement with BRIA"
BRIA RMBG-2.0	`bria-rmbg-2.0`, CC BY-NC 4.0	0.2B parameters; built on BiRefNet; 1024×1024	"subject to a commercial agreement with BRIA"
rembg (the Python tool)	MIT for the code	lists u2net, isnet, BiRefNet variants, SAM, and `bria-rmbg` (RMBG-2.0) as the default	its README says weights carry their own licenses, so check each; `bria-rmbg` "requires a paid agreement"
@imgly/background-removal (JS)	AGPL-3.0 for the library	model not named on the README page	README points to support@img.ly for other licensing; model license not stated there

The takeaway is not "avoid these". It is that "free to try in a browser" and "free to use in a product" are different grants. If you pull RMBG-1.4 or 2.0 into a commercial app, the card says you need a deal with BRIA. If you pick the AGPL JS library, the AGPL's obligations apply to what you ship. I am not a lawyer; read the license for your case.

Notice also what tools leave out. A page that says "powered by AI" and names nothing gives you nothing to check. A page that names RMBG-1.4 gives you a model card to read, including this license line. That is the honest value of naming the model.

2. Where do the pixels go: a script instead of a promise

Every vendor says "private". Your browser can tell you. I wrote a ~25-line Playwright script that opens a page, picks a file in its <input type="file">, waits, and lists every POST/PUT/PATCH with its size. If a request body is at least half the size of your image, it flags it.

// node upload-check.js <url> <image> [fileInputSelector]
const { chromium } = require('playwright');
const fs = require('fs');
(async () => {
  const [url, img, sel = 'input[type=file]'] = process.argv.slice(2);
  const size = fs.statSync(img).size;
  const browser = await chromium.launch();
  const page = await browser.newPage();
  const sent = [];
  // Blob/FormData bodies are streamed, so postData() is null for them.
  // Content-Length is the reliable size, so read that.
  page.on('request', async r => {
    if (!['POST', 'PUT', 'PATCH'].includes(r.method())) return;
    const h = await r.allHeaders();
    const b = r.postDataBuffer();
    const bytes = h['content-length'] ? +h['content-length'] : (b ? b.length : -1);
    sent.push({ method: r.method(), url: r.url(), bytes });
  });
  await page.goto(url);
  await page.setInputFiles(sel, img);
  await page.waitForTimeout(4000);            // let the tool finish
  console.log('image bytes:', size);
  for (const s of sent) {
    const verdict = s.bytes >= size * 0.5 ? 'LIKELY CONTAINS THE IMAGE' : 'small';
    console.log(s.method, s.url, s.bytes, verdict);
  }
  if (!sent.length) console.log('no request carried a body');
  await browser.close();
})();

My first version read request.postDataBuffer() and reported "no request carried a body" for an upload that was plainly happening. Playwright does not expose streamed Blob and FormData bodies that way. Reading Content-Length fixed it, and that is the kind of bug that makes a "privacy checker" lie in the comfortable direction.

I validated the script on three tiny pages of my own on localhost, using one 535 KB JPEG. These are mocks, not any vendor's site:

Mock page	Request	Bytes	Verdict
A: `fetch` with the file as body	`POST /upload`	534,844	likely contains the image
B: `FormData` (multipart)	`POST /api`	535,034	likely contains the image
C: processes locally, sends a small ping	`POST /analytics`	10	small

Limits you should know before trusting a green result:

A page could send a heavily downscaled or cropped copy. My 50% rule would miss it.
A chunked upload has no Content-Length, so the script prints -1. Treat -1 as "look manually".
WebSocket traffic and sendBeacon are not covered.
A model that runs locally still downloads from somewhere; a 40 MB model file is a GET, not a POST, so it will not show here. The first run being slower is normal for that design.

I did not run this against any vendor's website for this post. The script is a tool for you, on your own images; run it yourself and trust what you see.

3. Will the service be there

On the day I read it, remove.bg's own homepage carried a banner: background removal is moving to Canva, and "the standalone website will no longer be available from 1 December 2026 at 9:00am CET." The page did not say what happens to the API or accounts, so I won't guess. The moral is plain: a hosted service can be the right choice and still a dependency with an end date. A model you can run yourself (license permitting) does not have that problem, at the cost of the download and your own hardware.

What each service says about itself

All from the vendors' own pages, as read in Nov 2026. "Not stated" means the page I read doesn't say, not that the answer is no.

Tool	Where it processes	Retention	Limits / pricing notes	Model
remove.bg	cloud (upload)	not stated on the FAQ page; a feedback dialog says a negatively-rated image "will be used for future improvements" unless you decline	website closing 1 Dec 2026; FAQ lists up to 50 megapixels / 22 MB per image, free-tier applicability not stated	not named
Photoroom	not stated	links to its privacy policy	high-resolution export is a paid feature; "no signup required" in page metadata	not named
BgEraser	not stated ("directly in your browser", yet files are "deleted within 2 hours")	uploads and results deleted within 2 hours	batches of up to 20; "no sign-up or usage limits"; FAQ says commercial use of results is allowed if you have the rights to the original	not named
ToolTiny	the page says in the browser, via WebAssembly; "nothing is ever uploaded"	n/a (nothing uploaded, per the page)	about 40 MB model downloaded and cached on first use; "No file size limit" (in-browser, so your device's memory is the real limit; I did not test that); JPG, PNG, WebP in, transparent PNG out	RMBG-1.4 (BRIA AI), so the license above applies
ToolPix	not checked: its site blocks automated fetching	not checked	not checked	not checked

Two rows deserve a comment. BgEraser's page says you can use it "directly in your browser" and also says files are deleted within two hours; those two statements can both be true, but the page does not say where processing happens, and this is the case where the script above earns its keep. And for any tool built on RMBG-1.4, including the one in this table, "free" on the page and "non-commercial" on the model card are two different sentences; a site owner should read the second one.

A five-minute checklist

Find the model name. No name, no checking.
Open the model card and read the license line before a commercial use.
Run the upload script on a throwaway photo; investigate any -1 or flagged request.
Note any end-of-life banner or terms change, and keep an export of what you need.
Read the privacy policy for retention, then compare it with what the network tab showed.

Limits of this post

Vendor statements come from the pages as they read in Nov 2026 and may change; some pages were summarized by a fetch tool and I could not see their linked policies.
I did not benchmark edge quality (hair, fur, glass) for any tool; that needs a labeled image set, and I did not make one.
The upload check was tested on my own mock pages only.
The license table reports what each page states; licenses of other models (U-2-Net, BiRefNet and others) were not verified here.

If you know of a tool that publishes both its model license and a verifiable no-upload design, tell me and I will add a row.

Is your "free" image converter uploading your photos? A 2-minute test, and 3 ways conversion silently breaks images

Enlh NG — Tue, 15 Sep 2026 16:18:20 +0000

I convert images a lot, and two questions come up every time: did that tool just upload my file somewhere? and did the converted image come out the way it went in?

You can answer the first one yourself in about two minutes with the browser's built-in tools. The second one has three classic traps. I reproduced each of them with a few lines of Python, so you can see exactly what goes wrong and how to avoid it.

Part 1: the two-minute upload test

You don't need to trust a privacy page. Watch what the page actually does.

Open the converter and load the page fully.
Open DevTools (F12) → Network tab. Tick Preserve log, and click the clear (🚫) icon so the list is empty.
Drop in a test image. Use something unmistakable, like a photo around 3–5 MB.
Look at the new rows. Sort by Size or filter by Fetch/XHR:
- A POST or PUT whose request payload is about the size of your file (check the Payload tab, or the "Sent" size in some browsers) = your file left your machine.
- Nothing sizeable, just small analytics pings or fonts = processing is probably local.
For a second opinion, go offline (Network tab → throttling → Offline, or switch off Wi-Fi) after the page has loaded, then convert again. If it still works, it ran in your browser.

Caveats, so you don't draw the wrong conclusion:

A page that downloads a big decoder or model on first use will show large incoming transfers. That is not an upload. Look at what is sent.
"Offline works" proves local processing for that action. It doesn't prove the page never sends anything at another time (analytics, error reports). If it matters, read the requests.
A tool can be local for some formats and server-side for others. HEIC in particular needs a decoder that most browsers don't ship, so some tools quietly fall back to a server for it. Test each format you care about.

What the tools themselves say

Here's what I could verify from the sources themselves (checked Nov 2026; policies change, so re-check before relying on them):

Tool	Where processing happens	Source
Squoosh (Google Chrome Labs, Apache-2.0)	In your browser. README: "Squoosh does not send your image to a server. All image compression processes locally."	GitHub README
CloudConvert	Server-side. Privacy page: uploaded files "are automatically deleted after 24 hours at the latest"; you can delete earlier by hand.	Privacy page
TinyPNG	Home page states "up to 20 images, max 5 MB each." The privacy heading on the page had no answer under it, and I found no retention statement there.	tinypng.com

I'm not ranking these. The point is that "browser-based" and "deleted within a day" are very different promises, and the Network tab lets you check which one you got.

Part 2: three ways conversion silently breaks an image

These are bugs in pipelines, not in any one website. They show up in scripts and tools alike.

1. The sideways photo (EXIF orientation)

Phones often store pixels in the sensor's orientation and add an EXIF tag that says "rotate this when you display it." A converter that copies the pixels and drops the tag gives you a sideways image.

from PIL import Image, ImageOps

img = Image.open("phone-photo.jpg")
print(img.size, img.getexif().get(0x0112))   # (427, 640) 6  -> "rotate 90°"

naive = img.convert("RGB")                   # pixels only; the tag is gone
naive.save("naive.jpg")                      # displays sideways

fixed = ImageOps.exif_transpose(img)         # apply the rotation first
fixed.save("fixed.jpg")

![Left: correctly rotated. Right: pixels copied, EXIF dropped(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/ui7eahw4t8shv3bmr3cm.png)

I started from a sample photo and wrote it with orientation tag 6, which is what a portrait shot from a phone typically carries. After the naive conversion the tag is None and the picture displays on its side. (Modern browsers honour the tag when displaying a JPEG, which is why this bug often only appears after conversion.)

Check yours: convert one portrait photo straight from your phone and look at it in a viewer that doesn't auto-rotate. If it's sideways, the tool isn't applying orientation.

2. The black logo (transparency → JPEG)

JPEG has no alpha channel. What happens to transparent pixels depends on the code.

rgba = Image.open("logo-transparent.png")        # RGBA

bad = rgba.convert("RGB")                        # alpha just discarded
print(bad.getpixel((2, 2)))                      # (0, 0, 0)  -> black

bg = Image.new("RGB", rgba.size, (255, 255, 255))
bg.paste(rgba, mask=rgba.split()[3])             # flatten onto white first
print(bg.getpixel((2, 2)))                       # (255, 255, 255)

In my test the transparent corner pixel became (0, 0, 0), so a dark logo on a transparent background turns into a black blob. A good converter either lets you pick the background colour or warns you. If you're converting logos to JPEG, flatten onto the colour the page will actually use.

3. The disappearing metadata

When I re-saved that phone photo with only the pixels, the whole EXIF block was gone. That cuts both ways:

Good for privacy: camera model, timestamps and GPS coordinates don't travel with the file.
Bad for fidelity: orientation goes too (see above), and so can the embedded colour profile unless it's explicitly copied. Wide-gamut photos can look duller afterwards.

Check what's in a file before and after with exiftool photo.jpg (or the Properties dialog on your OS). Decide on purpose whether you want the metadata kept, and don't let a converter decide for you.

A safe conversion function

Here's the whole thing in a few lines, handling orientation and transparency, and deliberately stripping metadata:

from PIL import Image, ImageOps

def convert(path, out, fmt="WEBP", quality=80, bg=(255, 255, 255)):
    img = ImageOps.exif_transpose(Image.open(path))      # 1. apply orientation
    if fmt.upper() in {"JPEG", "JPG"} and img.mode in ("RGBA", "LA", "P"):
        img = img.convert("RGBA")                        # 2. flatten alpha
        flat = Image.new("RGB", img.size, bg)
        flat.paste(img, mask=img.split()[3])
        img = flat
    img.convert("RGB" if fmt.upper() in {"JPEG", "JPG"} else img.mode).save(
        out, fmt, quality=quality)                       # 3. no EXIF carried over

HEIC support is one pip install pillow-heif away (pillow_heif.register_heif_opener()), and in my test the library applied the rotation itself when opening, so it wasn't a source of sideways images.

If you'd rather not script it

For one-off files, a browser-based converter is fine, as long as you run the two-minute test above. I run a free image converter at ToolTiny, so apply the same test to mine as you would to any other.

Limits of what I showed

The orientation and transparency demos use Pillow. Other libraries differ in their defaults, and that's the point: test the tool you use.
I did not audit any specific converter's network traffic for this post; the Network-tab steps are how you can do that yourself. Policies in the table were read from the pages named, on the date shown.
EXIF behaviour varies by browser and viewer. When in doubt, compare in two apps.

If you've hit a conversion bug that isn't on this list, drop it in the comments. I'm collecting them.

I compressed 7 images 77 different ways. Here's what actually shrank (and what got ugly)

Enlh NG — Thu, 10 Sep 2026 15:14:46 +0000

Every "how to compress images" article tells you to "use WebP." I wanted to see how much that advice is worth, so I ran the same seven images through JPEG, WebP, AVIF and PNG at several quality settings, and measured two things: file size and how close the result is to the original.

Short version: the format matters less than which kind of image you have. Photos and graphics behave in opposite ways, and picking the wrong format for a graphic costs you more than any quality slider can save.

The setup

Images (7): five photos (a real fundus photo at 1411×1411, plus four standard sample photos at 512–640 px wide), one flat-colour bar chart (800×500) and one UI screenshot (1440×900).
Encoders: Pillow 12.3 (libjpeg, libwebp, libavif). JPEG at q95/85/75/60 (optimized + progressive), WebP at q85/75/60 (method=6), AVIF at q70/50, PNG lossless, and PNG reduced to 256 colours.
Quality metric: SSIM against the decoded original (1.0 = identical). It's a rough proxy for "looks the same", not a verdict from human eyes.
Units: 1 KB = 1,024 bytes throughout.
Baseline: every size below is shown as a percentage of the same image saved as JPEG q95, which is roughly what an export dialog gives you by default.

I tested the encoder libraries, not any website's pipeline. Online tools choose their own presets, so treat these numbers as "what the codecs can do", not "what tool X will give you".

from PIL import Image
im = Image.open("photo.png").convert("RGB")
im.save("out.jpg",  quality=75, optimize=True, progressive=True)
im.save("out.webp", quality=75, method=6)
im.save("out.avif", quality=70, speed=6)

Result 1: for photos, WebP q75 was smaller than JPEG q75 every time

(the SSIM axis starts at 0.88 to make differences visible)

Photo	JPEG q75	WebP q75	WebP vs JPEG size	SSIM JPEG / WebP
astronaut 512²	38.2 KB	24.0 KB	−37%	0.9405 / 0.9395
china 640×427	56.4 KB	49.0 KB	−13%	0.9414 / 0.9566
coffee 600×400	39.5 KB	28.7 KB	−27%	0.9083 / 0.9144
flower 640×427	25.5 KB	15.3 KB	−40%	0.9369 / 0.9368
fundus 1411²	104.3 KB	41.0 KB	−61%	0.9751 / 0.9568

On two photos WebP matched JPEG's SSIM almost exactly while being 37–40% smaller; on two it scored higher and was smaller; on the large photo it was 61% smaller but visibly scored lower (0.957 vs 0.975). So "WebP is 30% smaller" is a fair rule of thumb, but at the same number on the quality slider you don't get the same quality. Compare at matched SSIM, or just look at the result.

AVIF at q70 was often the closest to the original (highest SSIM on four of five photos) at a size that varied from smaller than JPEG q75 to slightly larger. At q50 it got very small, for example 29.0 KB against 138.5 KB for JPEG q95 on the china photo, but SSIM dropped to 0.92. I would not claim AVIF is "always smallest": with these default Pillow settings, it was not.

Result 2: for graphics and screenshots, JPEG was the worst choice

Image	PNG lossless	JPEG q75	WebP q75	PNG 256 colours
Flat bar chart	9.7 KB	14.4 KB	4.1 KB	4.4 KB
UI screenshot	86.0 KB	52.1 KB	26.9 KB	24.9 KB

For the flat chart, a lossless PNG (9.7 KB) beat JPEG q75 (14.4 KB), and JPEG q95 was 28.8 KB, three times the PNG. JPEG is built for noisy, continuous-tone photos. On sharp edges and flat colour it adds ringing artifacts and gets bigger.

The 256-colour PNG was the surprise winner for the screenshot: 24.9 KB at SSIM 0.994, with sharp text, roughly 29% of the lossless PNG size. WebP q75 was about the same size.

Result 3: 256-colour PNG on a photo is a trap

Quantizing a photo to 256 colours gave files 95–116% the size of JPEG q95, with an SSIM of only 0.89–0.96, plus colour banding. Palette PNG is great for graphics and pointless for photos.

Result 4: resizing beat every codec setting

Same fundus photo, WebP q75:

Dimensions	Size
1411×1411	41.0 KB
1000×1000	24.6 KB
700×700	15.0 KB

Dropping from 1411 to 1000 px saved more (−40%) than switching from JPEG q75 to WebP q75 did on three of the five photos (and the same as the best case). If your page displays an image at 700 px wide, shipping it at 3000 px is the real waste, and no quality slider fixes that.

What I'd actually do

Resize first to the largest size the page will display (×2 if you care about high-DPI screens).
Photos: WebP q75–80, or AVIF if your audience's browsers support it. Keep a JPEG fallback if you need one.
Screenshots, charts, logos, UI: PNG with a reduced palette, or lossless WebP. Never JPEG.
Look at the result at 100% zoom. A single metric (even SSIM) won't catch every artifact.

Tools, if you don't want to script this

Squoosh (Google Chrome Labs, Apache-2.0) is the one to reach for if you want to compare codecs side by side. Its README says it "does not send your image to a server."
TinyPNG is simple and fast; its page currently states "up to 20 images, max 5 MB each" (checked Nov 2026, so verify before relying on it), and I couldn't find a data-retention statement on the page.
ImageMagick/cwebp if you're comfortable on the command line: cwebp -q 75 -m 6 in.png -o out.webp.
I also run a free browser-based image compressor on ToolTiny with a live size preview, which is handy for one-off files.

Limits of this experiment

The photos are small by modern camera standards. Ratios usually hold on larger images, but I didn't test 12-megapixel files.
Seven images is a small sample. Results on your own images will vary, so run the script above on yours.
SSIM isn't perception. AVIF and WebP can blur fine texture in ways SSIM undervalues.
One encoder version (Pillow 12.3 / libwebp / libavif defaults). mozjpeg or a tuned avifenc would change the JPEG and AVIF rows.

If you try the script on your own images and get different numbers, I'd like to see them in the comments.

Top 5 Free Text Diff & Compare Tools Online (Privacy-First Options)

Enlh NG — Mon, 07 Sep 2026 06:42:57 +0000

The question that actually matters before pasting anything into an online diff checker: does this tool process the comparison on their servers, or entirely in your browser? If you're diffing API keys, a client contract, or proprietary code, that's not a minor detail — several popular diff tools upload your text to compare it, some even generate shareable public links by default. I compared 5 tools specifically on that axis, plus what each one actually does once the diff is computed.

1. ToolTiny — fully local, with a merge workspace and JSON-aware diffing

ToolTiny's Text Compare tool runs the entire diff — built on the jsdiff library — inside your browser tab, so nothing you paste or upload ever reaches a server. Word-by-Word mode handles contracts and prose; Line-by-Line handles config files, logs, and source code. You can paste directly or upload .txt, .log, .json, .py, .csv, and similar files without copy-pasting first.

Past the basic highlight-the-difference stage, it now covers what you'd expect from a full comparison workspace: a JSON-normalize mode that parses both inputs and sorts keys recursively before comparing, so two JSON files that only differ in key order or indentation correctly show as identical rather than flagging false differences; ignore-whitespace and ignore-case toggles; a live stats bar showing characters/lines added, removed, and modified alongside an overall similarity percentage; a minimap sidebar for jumping straight to a change in a long document; a merge panel where each changed segment gets its own "Keep Original" / "Keep New" choice, building a combined result you can copy out; and one-click export of the whole comparison as a self-contained HTML file. All of it still runs client-side — the feature list grew, the privacy model didn't change.

2. Diffchecker — the most polished workspace, with a privacy trade-off to know about

Diffchecker offers switchable views, a rule system to ignore timestamps, build numbers, or session IDs before comparing, and merge functionality with a genuinely refined interface. Free to try, unlimited on the paid tier. Worth knowing explicitly: Diffchecker's core convenience feature — shareable diff links — means comparisons can be processed and stored server-side rather than staying local to your browser. For non-sensitive comparisons where sharing a link matters more than privacy, that's a reasonable trade. For anything confidential, it's the one thing to check before pasting.

3. Mergely — built for developers who want to edit while diffing

The most code-editor-like interface here: syntax highlighting, line numbers, and inline editing directly within the diff view — you can fix either side of the comparison without leaving the tool and re-diff immediately. If your workflow is "compare, then fix what's wrong," this saves a copy-out-edit-copy-back cycle that even merge-panel tools like ToolTiny still involve.

4. EveryTool — the other fully-local option with a deep feature set

Also 100% browser-based using the Myers diff algorithm EveryTool (the same one Git uses): JSON mode, whitespace/casing filters, a minimap, live change counts with similarity percentage, and merge-by-accepting-individual-changes. It's a close match to ToolTiny feature-for-feature at this point — the meaningful difference is that ToolTiny also takes direct file uploads for common code and data formats, where EveryTool's flow is paste-based.

5. OnlineTextCompare — simplest two-way merge tool, fully local

A lighter-weight alternative to Mergely's full-editor approach: local processing, no signup, no usage limits, with arrow-based merging between the two versions. Good middle ground if you want basic merge capability without the deeper feature set of the tools above.

Quick comparison

Tool	Fully local	Merge function	JSON-aware diff	Notable feature
ToolTiny	✅	✅	✅ (key-order normalized)	Direct file upload + HTML export
Diffchecker	Partial (shareable links processed server-side)	✅	Not specified	Ignore-rules for timestamps/build numbers
Mergely	✅	✅	Not specified	Inline editing within the diff view
EveryTool	✅	✅	✅	Minimap, similarity %, HTML export
OnlineTextCompare	✅	✅	Not specified	Simple arrow-based merge, unlimited use

Which one for which situation

Comparing something confidential — contracts, API keys, proprietary code? ToolTiny, Mergely, EveryTool, or OnlineTextCompare — all fully local, nothing leaves your device.
Need to share a diff with a non-technical stakeholder via link? Diffchecker, understanding that means server-side processing.
Want to fix issues while comparing, not after? Mergely's inline editing is still the one dedicated tool for that specific workflow.
Comparing JSON files that might just be reordered or reformatted? ToolTiny or EveryTool — both normalize before diffing so formatting noise doesn't show up as a false change.
Want the result as a standalone file to attach to a ticket or email? ToolTiny or EveryTool's HTML export.

The honest note

"Runs in your browser" is doing real work as a phrase, but it's worth verifying rather than assuming for any tool not on this list. A diff tool with a "share this comparison" button is, by necessity, sending your text somewhere to generate that link — the convenience and the privacy guarantee are in direct tension, and a tool can't honestly offer both for the same feature. Before pasting anything you wouldn't want on a stranger's server, check specifically whether the tool's sharing or export features require a round-trip through their backend, not just whether the initial diff computation happens locally.

Paraphrasing tools without the hype: four ways text gets rewritten, and a short script that catches the damage

Enlh NG — Thu, 03 Sep 2026 14:51:31 +0000

Paraphrasing tools get compared by word limits and price. That's useful, but it skips the question that matters more: what did the rewrite do to my meaning?

Different tools rewrite text in fundamentally different ways, and each way breaks in its own way. Below I go through four approaches, what each one is good for, what free tiers currently allow (read from the vendors' own pages), and a small Python script that flags the most common damage: dropped numbers, lost names and flipped negations.

Four ways text gets rewritten

Approach	How it works	Good at	Typical failure
Synonym swap	Replace words using a thesaurus or rules	Fast, predictable, keeps structure	Wrong sense of a word ("bank" the river vs the institution), awkward phrasing
Back-translation	Translate to another language and back	Produces genuinely different phrasing without a language model rewriting your content	Can drift on idioms, jargon and tone
LLM rewrite	A language model rewrites to a requested style (formal, shorter, simpler)	Fluent output, controllable tone and length	Can silently change facts, drop qualifiers or invent detail
Manual	You rewrite it	Full control	Slow

None of these is "the best". They suit different jobs: tightening an email (LLM or manual), simplifying a dense paragraph (LLM), getting a second phrasing of a short sentence (back-translation or synonym swap), preserving exact technical wording (usually manual, or don't paraphrase at all).

Here are illustrative failures I wrote to show the kinds of damage to look for (they're examples, not outputs from any specific product):

Original	Rewrite	What changed
"The API is not free; it costs $20 per month for 5 users."	"The API costs $20 monthly for 5 users."	The negation vanished
"In March 2024, Dr. Alvarez found the drug did not reduce symptoms in 62% of patients."	"Dr. Alvarez found in early 2024 that the medication reduced symptoms in most patients."	The meaning inverted and the number was lost
"The meeting moves to 14:30 on Friday."	"The session is now at 15:30 on Friday."	A number was quietly altered

Fluent output hides these errors, because the rewritten sentence reads smoothly. That's why a mechanical check is worth having.

A short "did the meaning survive?" checker

It compares three things between your original and the rewrite: numbers, names (capitalised words in the middle of a sentence) and negations. It won't understand meaning. It only catches the cheap, high-impact mistakes.

import re

NEGATIONS = {"not", "no", "never", "none", "cannot", "can't", "won't", "isn't", "aren't",
             "doesn't", "don't", "didn't", "without", "neither", "nor"}

def tokens(text):
    text = re.sub(r"['’]s\b", "", text.lower())          # France's -> france
    return set(re.findall(r"[a-z']+", text))

def numbers(text):
    return {n.rstrip(".,:;-") for n in re.findall(r"\d[\d,.:%/-]*", text)}

def mid_sentence_caps(text):
    out = set()
    for sent in re.split(r"(?<=[.!?])\s+", text):
        words = re.findall(r"[A-Za-z][A-Za-z'’-]*", sent)
        out |= {w for w in words[1:] if w[0].isupper()}
    return out

def check(original, rewrite):
    report = {}
    lost, new = numbers(original) - numbers(rewrite), numbers(rewrite) - numbers(original)
    if lost or new:
        report["numbers"] = {"lost": sorted(lost), "added": sorted(new)}
    rt = tokens(rewrite)
    names = sorted(w for w in mid_sentence_caps(original) if w.lower() not in rt)
    if names:
        report["names"] = {"lost": names}
    ot = tokens(original)
    lost_n, new_n = sorted((ot & NEGATIONS) - (rt & NEGATIONS)), sorted((rt & NEGATIONS) - (ot & NEGATIONS))
    if lost_n or new_n:
        report["negations"] = {"lost": lost_n, "added": new_n}
    return report

Running it on the examples above:

>>> check("The API is not free; it costs $20 per month for 5 users.",
...       "The API costs $20 monthly for 5 users.")
{'negations': {'lost': ['not'], 'added': []}}

>>> check("In March 2024, Dr. Alvarez found that the drug did not reduce symptoms in 62% of 1,200 patients.",
...       "Dr. Alvarez found in early 2024 that the medication reduced symptoms in most of 1,200 patients.")
{'numbers': {'lost': ['62%'], 'added': []},
 'names': {'lost': ['March']},
 'negations': {'lost': ['not'], 'added': []}}

>>> check("The meeting moves to 14:30 on Friday, and Maria will attend.",
...       "The session is now at 15:30 on Friday; Maria will be there.")
{'numbers': {'lost': ['14:30'], 'added': ['15:30']}}

>>> check("Paris is the capital of France.", "France's capital city is Paris.")
{}

The last case is the check working as intended: a valid rewrite produces an empty report. Limits: it's English-only, it can't see a changed verb ("increase" → "decrease"), and it will flag harmless changes such as "March 2024" → "early 2024". Treat it as a smoke alarm, not a judge.

What free tiers allow (read from the vendors' pages, Nov 2026)

Limits change often, so check the page before relying on any of this.

Tool	Free input limit	Free modes	Other stated details	Source
QuillBot	"up to 125 words at a time"	Standard and Fluency; eight other modes are marked Premium	Page says no daily limit on free paraphrases	quillbot.com
Paraphraser.io	The page gives two different figures: "600 words limit free of cost" in the price section, and a "0 / 400" counter in the tool	Word changer, fluency, standard, formal and smooth, per the price section	"Unlimited text without any daily limit"; 20+ languages; the page has no statement on how your text is stored	paraphraser.io

Two observations, both from reading those pages:

A per-input cap and "no daily limit" can both be true: you can run unlimited chunks of 125 words. For a long article, that means splitting and re-checking transitions between chunks, which is exactly where meaning and tone drift.
Where a page doesn't state data handling, I haven't assumed anything. If you're pasting confidential text into any online tool, read its privacy policy, or use the DevTools Network tab to see whether your text leaves the page.

I run a free paraphraser at ToolTiny, so I'm not going to rank it against these. Read its limits on the page itself like you would for any other.

When paraphrasing is the wrong tool

Academic work: rewriting a source doesn't remove the need to cite it. The University of Virginia's honor committee puts it plainly: "paraphrasing without citing the original source is considered plagiarism" (source).
Detection is moving too. In September 2025 Turnitin announced "AI bypasser detection," aimed at text that tools have modified to hide AI use. Coverage at the time noted it was limited to English and gave no accuracy figures (THE Journal). I'm not suggesting any tool should be used to evade that. The point is that a rewrite is not a substitute for your own understanding of the source.
Legal, medical and technical text: precise wording often is the content. Rephrase the explanation around it, and quote the exact sentence.

A simple workflow that holds up

Paste short chunks (a paragraph at most), not whole documents.
Pick the approach that matches the job (table above).
Run check(original, rewrite), then read the rewrite aloud once.
Reread numbers, names and negations by hand. The script is a filter, not a proof.
Cite the source if the ideas aren't yours.

Limits of this post

The failure examples are illustrative and I wrote them myself; I did not benchmark any named tool's rewrite quality.
The checker looks at three surface features of English text. It will miss subtle meaning changes and produce some false alarms.
Tool limits are as stated on the vendor pages on the date I read them, and they change.

If you have a rewrite that fooled the checker, paste it in the comments and I'll see whether the script can be improved.

My lorem ipsum generator promised an exact character count and hit it 15% of the time

Enlh NG — Fri, 28 Aug 2026 06:20:05 +0000

I run a small lorem ipsum generator. It has a "Characters" mode, and the page's FAQ said this about it:

Produces text trimmed to the exact character count, without cutting off in the middle of a word.

I never tested that sentence. Last week I did, with 2,000 runs per setting. The function hit the requested length about 15% of the time. That is not a rounding error, it is a broken promise, so this post is the test, the numbers, and the fix, including the part of the fix that I think is still a compromise.

Why anyone needs an exact count

Lorem ipsum by paragraph is fine for layouts. Exact characters matter when the container is strict: a meta description field, a 160-character SMS preview, a database column with VARCHAR(100), a tweet-sized card, a form validation test that needs a string of exactly the limit and one over it. "About 160" is useless there, because the bug you are hunting lives at 160 and 161.

Three ways to produce N characters

1. Cut at the limit.

text.slice(0, n)

Always the right length. But the last word is cut in the middle most of the time, and the text rarely ends in punctuation.

2. Trim back to the last space (what my page did). Generate more text than needed, cut at n + 1, move back to the last space, strip trailing ,;:, add a period.

let cut = text.slice(0, n + 1);
cut = cut.slice(0, cut.lastIndexOf(' ')).replace(/[,;:]+$/, '');
if (!/[.!?]$/.test(cut)) cut += '.';

It never cuts a word. It also lands on the target only when a word boundary happens to sit at exactly position n, and that is luck.

3. Search, then fall back to a cut. Repeat approach 2 on freshly generated text until the length equals n (up to 80 attempts). If none fits, hard-cut to n - 1 characters and append a period, swapping a trailing space or comma for a letter so the output doesn't end in , ..

function hardCut(text, n) {
  let s = text.slice(0, n - 1);
  if (/[\s,;:\-]$/.test(s)) s = s.slice(0, -1) + "e";
  return s + ".";
}

The test

The generator builds sentences from a fixed vocabulary, so I could check three properties on every output:

length === n
it ends with ., ! or ?
the last token is a whole word from the vocabulary (not a fragment)

I loaded the original function and the patched one into Node with vm, and ran each for targets 20, 50, 100, 160, 280, 500, 1000 and 5000, in three styles, 2,000 runs per cell. Classic style, n = 160:

	exact length	whole last word	when not exact
`slice(0, n)`	100%	19%	n/a
Trim to last space (my original)	14.8%	100%	short by 4 on average, up to 13
Search, then hard cut	100%	100%	n/a

The other targets from 100 to 5,000 look the same: the original is exact 14–16% of the time in classic style. Hipster was 11–14% and corporate 10% in my runs. It never overshoots (it always cuts back), so every miss is short, never long. The first user-visible symptom would be "I asked for 160 and got 156", which is easy to blame on the user's counting.

The case where exactness and clean words disagree

The page has a "Start with Lorem ipsum dolor sit amet…" option, and that prefix is 55 characters. With the prefix on and a small target, there is no sentence structure that both ends on a whole word and totals exactly n:

target	original	new
20	`Lorem ipsum dolor.` (18 chars, never 20)	`Lorem ipsum dolor s.`
50	`Lorem ipsum dolor sit amet, consectetur.` (40)	`Lorem ipsum dolor sit amet, consectetur adipiscin.`

In these two cases (n = 20 and 50 with the prefix on) the new code falls back to the hard cut in 100% of runs. So the contract became: exact length always; whole words whenever the arithmetic allows it. With the prefix off, targets 20 and 50 fit cleanly. For n ≥ 100 in classic style the fallback fired in 0 of 2,000 runs per target, and at most 0.1% in hipster and corporate.

Is adipiscin. acceptable lorem ipsum? For a length test, I think yes, and the alternative is a wrong length, which is the whole thing the mode exists to prevent. But it is a trade-off, and the FAQ should say so.

Does a search loop cost anything?

I counted attempts before a clean fit over 5,000 samples per target in classic style:

mean about 6.8, median 5
95th percentile about 20, 99th about 30
max 47–66 depending on target; never reached the 80-attempt cap

Each attempt generates a few hundred characters of text; I did not time it in a browser, so check that on your own target. If your vocabulary has longer words, the odds of an exact fit per attempt drop and the cap matters more. Measure rather than copy my 80.

A short detour: where the text comes from

The classic text is not random Latin. It is scrambled text from Cicero's De finibus bonorum et malorum (sections 1.10.32–33, 1st century BC), and it was traced there in the 1990s by Richard McClintock of Hampden–Sydney College, who looked up the rare word consectetur. Per Wikipedia, in a 2026 interview he said his earlier claim that the passage dates to the 1500s was a guess. Letraset sheets used it from 1966. It reads like Latin and carries no meaning, so reviewers look at the layout instead of the copy.

What the other generators say about exactness

Everything below is from each vendor's own page, as read in Nov 2026. "Not stated" means the page does not say.

Generator	Units offered	Exact characters	Runs where
lipsum.com	paragraphs, words, bytes, lists	not stated (has bytes)	not stated
FlipMyCase	up to 20 paragraphs, 50 sentences or 500 words; 5 styles	not a unit (shows a character count)	browser, text "never sent to a server"
ToolTiny	paragraphs 1–50, sentences 1–100, words 1–500, characters 20–5,000; Classic, Hipster, Corporate, Standard	yes, per the tests above	browser

I could not read LoremGen's and Genie9's pages (their robots.txt blocked my fetch), so I make no claim about them. Note that "bytes" and "characters" differ for non-ASCII text, which does not matter for lorem ipsum but does matter if you use the counts for other scripts.

Checklist if you write your own

Say in the UI which property wins when two conflict (exact length vs whole words).
Test the boundaries: the smallest allowed target, and a target equal to your prefix length.
Assert length === n in a loop with many runs, not one run.
Remember that JavaScript's length counts UTF-16 code units. It is exact for this ASCII vocabulary, not in general.
Cap the retry loop and have a deterministic fallback.

Limits of this test

The vocabulary is my own, synthetic, with its own word-length distribution; a different one changes the hit rate of the trim approach.
One JavaScript engine (Node 22). The string operations are standard, but I did not run other engines.
"Original" means the function as it was when I started this test, and the page now uses the new one.
Vendor statements are as of Nov 2026 and may change.

If you have a different approach to hitting an exact length without a mid-word cut (padding with a short word, choosing the vocabulary words to fit the remainder), I would like to compare it with the same harness.

Top 5 Free Online Case Converters (camelCase, snake_case, PascalCase & More)

Enlh NG — Sun, 23 Aug 2026 15:26:02 +0000

Renaming a Python snake_case API response into camelCase for your JavaScript model, or turning a blog title into a URL slug, is exactly tedious enough to be annoying and exactly simple enough that firing up a script feels like overkill. A browser-based case converter fixes it in one paste. I compared 5, specifically for format coverage and — the detail that actually separates the good ones from the rest — whether they correctly parse text that's already in some other case format.

1. ToolTiny — 12 formats, with word-boundary detection that actually works

ToolTiny's Case Converter covers Sentence case, lowercase, UPPERCASE, Title Case, camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case, URL slug, and alternating case — 12 formats, all client-side, no character limit, nothing you paste ever leaves your browser.

The detail worth actually testing rather than taking on faith: paste in XMLHttpRequest and ask it for snake_case. A naive converter either treats the whole string as one word or garbles the acronym into x_m_l_http_request. ToolTiny splits it correctly into xml_http_request — it detects camelCase/PascalCase boundaries and acronym runs before converting, so renaming an existing identifier between conventions doesn't require you to manually add spaces first. Same logic applies going the other direction: paste user_registration_date and hit camelCase, you get userRegistrationDate, not Userregistrationdate.

2. FWD Tools — 14 formats with the same boundary-splitting approach

Covers everything ToolTiny does plus Train-Case and COBOL-CASE, converting all 14 simultaneously so you paste once and copy whichever result you need. Also splits on existing camelCase boundaries before reformatting — getUserProfileData correctly becomes four separate words rather than one blob. If you want every result visible at once instead of clicking between buttons, this is the more convenient layout.

3. App DevTools — curated specifically around programming conventions

12 formats, deliberately scoped toward code rather than general writing: PascalCase, CONSTANT_CASE, dot.case, kebab-case, path/case, Train-Case, and Pascal_Snake_Case alongside the standard set. If you want a tool that isn't cluttered with novelty formats and stays focused on what you'd actually use while coding, this is the most tightly curated option here.

4. toolk.site — the other tool that gets acronyms right

13 formats, and specifically calls out the same acronym-boundary handling as ToolTiny: XMLHttpRequest correctly becomes xml_http_request rather than the garbled character-by-character version. Worth knowing this isn't universal — several case converters on the market still get acronyms wrong, so if you're evaluating one not on this list, that's the one thing worth testing before you trust it with real code.

5. OnlineWebToolkit — broadest coverage at 17 formats

The largest format list here, split into three groups: human-readable (Title Case, Sentence case), creative/novelty (alternating case, inverse case), and developer conventions (camelCase, snake_case, PascalCase, kebab-case, and the rest). If you want one tool that covers essentially every case format you'll ever encounter without switching tools, this is the widest net, even if you'll rarely touch most of the novelty formats.

Quick comparison

Tool	Format count	Handles acronyms correctly	Notable feature
ToolTiny	12	✅	No character limit, URL slug generator
FWD Tools	14	✅	All formats shown simultaneously
App DevTools	12	Not specified	Curated for programming use only
toolk.site	13	✅	Same acronym handling as ToolTiny
OnlineWebToolkit	17	Not specified	Broadest format coverage overall

Which one for which situation

Renaming identifiers between languages (Python snake_case ↔ JavaScript camelCase, database columns ↔ API fields)? ToolTiny, FWD Tools, or toolk.site — all three parse existing case boundaries and acronyms correctly, which matters more than the format count once you're past the basics.
Want every format visible at once instead of switching buttons? FWD Tools' simultaneous-output layout.
Text has heavy acronym use (API, XML, HTTP mixed into identifiers)? Specifically verify with a test paste — ToolTiny and toolk.site both handle it; not every converter does.
Want one bookmark that covers every format you'll ever need, novelty formats included? OnlineWebToolkit's 17-format spread.

The honest note

"Case converter" sounds like a solved, interchangeable-tool category, and mostly the basic formats are — but acronym and boundary handling genuinely isn't universal, and it's the thing that actually breaks in practice. A converter that treats XMLHttpRequest as one indivisible word will silently produce garbage the moment you feed it a real codebase identifier instead of a demo string. Before trusting any case converter with a bulk rename — database columns, API fields, anything at scale — paste in one identifier you know contains an acronym and check the output by hand. It takes ten seconds and it's the actual test that separates a converter built for prose from one built to handle code.

My "one-time token" handed out the real API key in two requests

Enlh NG — Thu, 20 Aug 2026 12:37:42 +0000

I run a free speech-to-text page that calls a paid transcription API. The API key must never reach the browser, so I added what I thought was a careful design: the page asks my server for a temporary token, the token lasts 30 seconds, and it works only once.

Then I wrote a test for it, and the test showed that anyone could get the real key in two requests. This post shows the old code, the measurements, the proxy that replaced it, and the ten tests I use now. All keys in the examples are fake.

The design that felt safe

This is the old code, shortened:

_stt_tokens = {}            # { token: {"key": "gsk_...", "expires": ts} }

@app.get("/api/stt-token")
async def get_stt_token():
    """Token holds the real API key and expires after 30 seconds.
    The key never appears in the HTML/JS source."""
    token = secrets.token_urlsafe(32)
    _stt_tokens[token] = {"key": next_key(), "expires": time.time() + 30}
    return {"token": token, "expires_in": 30,
            "groq_url": "https://api.groq.com/openai/v1/audio/transcriptions",
            "model": "whisper-large-v3-turbo"}

@app.post("/api/stt-token/validate")
async def validate(token: str = Form(...)):
    entry = _stt_tokens.pop(token, None)      # single use
    if not entry or time.time() > entry["expires"]:
        raise HTTPException(401, "Invalid or expired token")
    return {"key": entry["key"]}              # <- the real key

The page would fetch a token, exchange it for the key, and call the transcription API straight from the browser. The docstring I wrote even argued why this was safe: the key is not in the source, the token is random, it expires, it is single-use, and I can rate-limit the token endpoint.

Every one of those statements was true. None of them protected the key.

The two requests

I rebuilt just those two endpoints in a test app with a fake key and called them as any visitor could:

1) GET  /api/stt-token          -> 200 ['token', 'expires_in', 'groq_url', 'model']
2) POST /api/stt-token/validate -> 200 {'key': 'gsk_FAKE_KEY_FOR_DEMO_0000...'}
   same token again             -> 401 {'detail': 'Invalid or expired token'}
3) 1000 token->key exchanges in 3.13s, no rate limit, distinct keys obtained: 1

The token is single-use, as promised. But the thing it unlocks is the key itself, and nothing stops a visitor from asking for a new token. A thousand exchanges took 3.1 seconds in my sandbox, and I had not written the rate limit the docstring said I could add. Two curl calls are enough, and you do not even need the page.

What the token actually protected

What I wrote	What it protects against	What the attacker wanted
Key is not in the source	Someone grepping my HTML	The key
Token is random	Guessing a token	The key
Expires in 30 seconds	Re-using an old token	The key
Single use	Replaying a token	The key

All four controls guard the token. The asset was the key, and the design had a door that exchanged tokens for it. If the browser is going to use the key, then the visitor has the key. A short lifetime only helps when what you hand out is itself a short-lived credential (for example a signed upload URL) and not the long-lived secret.

Any key that was ever served by such an endpoint has to be treated as leaked, whatever the token lifetime was. Rotate it.

The fix: the browser never sees a key

Instead of giving the browser a credential, the server now does the call. The page posts the audio file to /api/stt on my own server, and the server forwards it to the transcription API with the key attached:

@app.post("/api/stt")
async def speech_to_text(request: Request, file: UploadFile = File(...),
                         language: str = Form(""), response_format: str = Form("json")):
    if not _stt_rate_ok(_stt_client_ip(request)):
        return _stt_error(429, "Rate limit reached. Please wait a minute and try again.")
    if os.path.splitext(file.filename or "")[1].lower() not in _STT_EXTS:
        return _stt_error(400, "Unsupported format. Please upload MP3, MP4, WAV, M4A, OGG, FLAC or WebM.")
    lang = language.strip().lower()
    if lang == "nb": lang = "no"
    if lang and not re.fullmatch(r"[a-z]{2,3}", lang):
        return _stt_error(400, "Invalid language.")
    ...

Several details matter more than the happy path:

Validate before you spend anything. Rate limit first, then file extension, then the language code (a 2 or 3 letter string; the transcription API documents ISO-639-1 codes, and I map nb to no). Nothing is forwarded until all three pass.

Cap what you load into memory. The upload is read in 1 MB chunks, and the request is refused with 413 as soon as the running total passes 25 MB, because that is the limit of the free tier of the API I call. This bounds what my code holds in RAM. It does not stop the web framework from receiving and spooling a huge upload before my function runs, so the real size limit also belongs in the reverse proxy (in Nginx, client_max_body_size).

Limit concurrency. A semaphore allows two files in flight per worker, and a request that cannot get a slot within 20 seconds gets a 503. Without it, a burst of 25 MB uploads can exhaust memory, because each file is held in RAM.

Retry once on the next key. When the provider answers 429, the code retries once with the next key in a round-robin list. The test below checks that the second attempt really uses a different key.

Never forward upstream error text blindly. Only 400, 413 and 422 from the provider pass a message on, because those describe the user's file. A 401, a 5xx or a network error becomes a generic 502 ("service unavailable"), so a provider error that mentions a credential cannot reach the visitor.

The ten tests

I run these against a fake HTTP client, so no real API is called:

#	Case	Expected	Result
1	Valid file, `language=nb`, `verbose_json`	200, upstream gets `language=no`, response has no `gsk_`	passed
2	`.exe` file	400	passed
3	Empty file	400	passed
4	Language `xx1!`	400	passed
5	25 MB + 1 byte	413	passed
6	Provider returns 429 once	200, second call uses another key	passed (`fake2`, then `fake1`)
7	Provider returns 400 "file is not valid audio"	400 with that message	passed
8	Provider returns 401 "Invalid API Key gsk_secret"	502, key text not in response	passed
9	Network error	502	passed
10	Six requests from one IP	200 four times, then 429	passed (`[200, 200, 200, 200, 429, 429]`)

After all ten, the semaphore had both slots free again, which is how I check that no code path leaks a slot.

Test 8 is the one I care about most. It is the test that would have caught a naive proxy that returns the provider's error body.

What is still imperfect

The rate limit is in memory and per worker. With two workers the real limit is about double the number in the code (4 a minute and 30 a day per IP, per worker). That is fine for a free tool, but it is not a precise quota.
The IP comes from X-Real-IP. That is only trustworthy if Nginx sets it and the app port is closed to the internet. Otherwise a client can invent a new IP on every request.
The whole file sits in memory while it is forwarded. The size cap and the semaphore bound it, but they do not remove it, and the size check in my function runs after the framework has already parsed the upload.
The audio does leave my server. It goes to a third-party API (Whisper large-v3-turbo, hosted by the provider). My code does not write it to disk, and the provider's docs page that I read does not state a retention period, so I cannot promise anything about what happens on their side.

Where the options differ (read Nov 2026)

If you only need a transcript, you may not want to build any of this. I tested my own code, not these sites; this is what each page states, and "not stated" means I did not find it on the page I read.

Option	What it takes	Limits	Where the audio goes
Groq speech-to-text API (the engine behind my proxy)	An API key	25 MB per file on the free tier, 100 MB on the dev tier; flac, mp3, mp4, mpeg, mpga, m4a, ogg, wav, webm	Their servers; retention not stated
FastTranscriber	A guest can upload without an account	2 uploads per day; TXT and SRT export; 98+ languages; file size not stated for the free tier; "20-minute transcript previews"	"Private & Secure" badge; retention not stated
Speechnotes	Dictation needs no account	Dictation free; file transcription $0.1 per minute; dictation engines are "Google & Microsoft"	Recordings "deleted from our servers as soon as the transcription is done"; dictation notes stay in the browser
Otter.ai free plan	An account	300 minutes per month, 30 minutes per conversation, 3 lifetime file imports, six languages	Not stated on the pricing page
Whisper Web	Nothing to sign up for	Not stated	The page does not say whether the work happens on your device, so I do not claim it
ToolTiny (my page)	No sign-up	25 MB, the formats above; 4 requests a minute and 30 a day per IP per worker	File goes through my server to the provider's API; not written to disk by my code; provider retention not stated

The row I could not verify is Whisper Web. I used to describe it as running entirely on your device, but the page I read does not say that, so I am not repeating it.

Checklist before you proxy a paid API

Never send a long-lived key to a browser, not even for 30 seconds. Hand out a credential only if it is itself short-lived and limited.
Write the exploit as a test before you write the defence, and run it against the code you actually deploy.
Validate cheap things first (rate, type, language), then read the body with a size cap, then spend money.
Bound concurrency and memory, and test that a slot is released on every path.
Map provider errors to generic ones unless the message is about the user's input.
Rotate any key that was ever exposed.

Limits of this post

The old endpoints were rebuilt from my own code in a test app with a fake key, and nothing contacted a real service. The numbers (a thousand exchanges in 3.1 seconds) come from my sandbox, not from a production server.
The ten tests use a fake HTTP client. They show how my code handles each response, not how the real provider behaves.
I did not measure transcription accuracy or speed in this post.
Memory use of the proxy was not measured. I only describe how it is bounded.
Vendor statements are as they appeared on the day I read them.

If you have found a safe way to let a browser call a paid API directly, I would like to hear what you hand out. Tell me in the comments.

I Couldn't Finish Reading a 20-Page PDF Without Losing Focus. Listening to It Changed That

Enlh NG — Mon, 17 Aug 2026 09:18:30 +0000

Turns out the problem was never "I'm bad at reading." It was that I'm bad at reading silently, alone, for long stretches.

Grad school assigned readings that were routinely 20-30 pages of dense academic PDFs, and I'd sit down with every intention of getting through one, and twenty minutes later realize I'd read the same paragraph four times without absorbing a word of it. I assumed this meant I just needed more willpower, more coffee, a quieter room. None of that fixed it.

What actually fixed it, almost by accident, was a text-to-speech tool a classmate mentioned offhand. I pasted a reading into it, put in one earbud, and kept following along on the screen while it read to me. I finished the whole thing in one sitting for the first time in months. It wasn't that the reading got easier — it's that hearing it and seeing it at the same time gave my attention somewhere consistent to land.

What actually changed

I'm not diagnosed with anything, for what it's worth — I just apparently focus differently with combined audio and visual input than with silent reading alone. Turns out that's genuinely common, not some special trick, and it's the same reason text-to-speech is a standard accessibility tool for dyslexia, ADHD, and visual fatigue. I just hadn't tried it because I didn't think of myself as someone who "needed" it.

What I use now

ToolTiny — my default for anything I don't want uploaded anywhere, which turned out to be most of grad school (unpublished drafts, other people's unpublished work, personal notes). It runs entirely inside your browser using built-in voices, so the text never actually leaves your device — not "we delete it after," genuinely never sent anywhere. You get a real range of voices and languages, and you can slow the speed down, which I do constantly for denser material. The voices sound a little more robotic than the AI ones below, but for reading my own study material, I stopped noticing that within a few minutes.

👉 tooltiny text to speech

FreeTTS — I use this when the audio itself is the point — recording something to actually share, not just for my own listening. The voices sound close to a real person, no signup, and you can generate as many times as you want without hitting a daily wall.

Edge Read Aloud — if I'm reading an article directly on a website rather than something I've saved, this is built into the browser already and needs zero setup. I don't even think of it as a separate tool at this point, just a button I click.

What I'd tell someone who assumes this isn't "for them"
Struggling to get through long readings, no official diagnosis, just can't focus silently? Try it before assuming it's a willpower problem. It might just be how your attention works.
Reading something private or unpublished? ToolTiny — it never uploads anything.
Want the most natural-sounding voice for something you're sharing? FreeTTS.
Reading directly on a webpage? Whatever your browser's built-in reader is — check for it before installing anything.
The trade-off nobody explains upfront

The tools that sound the most human — the ones that don't sound like a voice assistant at all — are cloud-based, meaning your text gets sent somewhere to generate that quality. The tools that keep everything fully private, running only on your own device, sound noticeably more synthetic in comparison. Neither one is "better" universally. I use the private, slightly robotic option for my own study material and drafts, and I'd use the more natural-sounding one if I were ever making something to actually share publicly. Once I understood that trade-off existed, picking got a lot easier.

I still can't read a dense PDF silently in one sitting. I just don't have to anymore.

DEV Community: Enlh NG

Migrating legacy .doc/.xls/.ppt files: a runbook with acceptance tests (28 of 29 checks survived, plus one trap)

Step 0: know what "conversion" is in your pipeline

Step 1: pre-flight, because the converter will say "success" on junk

Step 2: convert with a private profile and a timeout

Step 3: post-flight, because exit code 0 is not proof

Step 4: acceptance tests: what does a conversion keep?

The trap: converting back loses data silently

"Modern files are smaller": not always

What an online converter says about itself

Checklist for your own migration

Limits of this write-up

Same contract, seven variants: what should a Word diff flag, and what do three methods actually flag?

Setup

Results

What I learned from each row

The comparison functions

Choosing a tool: the questions come from the table above

Limits of this experiment

The checklist I took from it

Top 10 ways merging and splitting Excel files goes wrong (each one reproduced)

1. Rewriting through pandas keeps the values and nothing else

2. A file nobody has opened in Excel has no formula results

3. data_only=True plus save() deletes your formulas for good

4. Formulas that point at a sheet the new workbook does not have

5. Sheet names have rules, and some are enforced quietly

6. IDs with leading zeros become numbers

7. Merged cells only keep one value

8. Stacking rows needs normalized headers

9. The sheet has a hard row limit

10. Two workbooks can use different date systems

If you would rather not code

The reproduction script

Limits

A free AI background remover is three questions: which model, which license, where do the pixels go

1. Which model, and under what license

2. Where do the pixels go: a script instead of a promise

3. Will the service be there

What each service says about itself

A five-minute checklist

Limits of this post

Is your "free" image converter uploading your photos? A 2-minute test, and 3 ways conversion silently breaks images

Part 1: the two-minute upload test

What the tools themselves say

Part 2: three ways conversion silently breaks an image

1. The sideways photo (EXIF orientation)

2. The black logo (transparency → JPEG)

3. The disappearing metadata

A safe conversion function

If you'd rather not script it

Limits of what I showed

I compressed 7 images 77 different ways. Here's what actually shrank (and what got ugly)

The setup

Result 1: for photos, WebP q75 was smaller than JPEG q75 every time

Result 2: for graphics and screenshots, JPEG was the worst choice

Result 3: 256-colour PNG on a photo is a trap

Result 4: resizing beat every codec setting

What I'd actually do

Tools, if you don't want to script this

Limits of this experiment

Top 5 Free Text Diff & Compare Tools Online (Privacy-First Options)

1. ToolTiny — fully local, with a merge workspace and JSON-aware diffing

2. Diffchecker — the most polished workspace, with a privacy trade-off to know about

3. Mergely — built for developers who want to edit while diffing

4. EveryTool — the other fully-local option with a deep feature set

5. OnlineTextCompare — simplest two-way merge tool, fully local

Quick comparison

Which one for which situation

The honest note

Paraphrasing tools without the hype: four ways text gets rewritten, and a short script that catches the damage

Four ways text gets rewritten

A short "did the meaning survive?" checker

What free tiers allow (read from the vendors' pages, Nov 2026)

When paraphrasing is the wrong tool

A simple workflow that holds up

Limits of this post

My lorem ipsum generator promised an exact character count and hit it 15% of the time

Why anyone needs an exact count

Three ways to produce N characters

The test

3. `data_only=True` plus `save()` deletes your formulas for good