DEV Community: 코딩나우(하늘아래)

WiFi QR codes: the five escapes, the all-hex SSID trap, and what ECC level H costs you

코딩나우(하늘아래) — Wed, 30 Sep 2026 03:24:32 +0000

The payload behind a "join this network" QR code is a single line of text:

WIFI:T:WPA;S:cafe-wifi;P:p@ssw0rd;;

Worth knowing up front: this is not an official standard. It is the convention ZXing introduced, which the early Android scanners shipped with, and which everything else then matched. There is no RFC to point at when something disagrees.

Which matters, because the moment a password contains punctuation, the format starts biting.

Five characters have to be escaped

Inside S: and P:, a backslash escapes the five characters that would otherwise end a field: \ ; , : ".

So I built payloads for a set of passwords and parsed them two ways — once by naively splitting on ; and : (how you write it the first time), once following the escape rule:

  password 'p@ssw0rd'
     payload   WIFI:T:WPA;S:cafe-wifi;P:p@ssw0rd;;
     naive     'p@ssw0rd'          OK
     spec      'p@ssw0rd'          OK

  password 'coffee;time'
     payload   WIFI:T:WPA;S:cafe-wifi;P:coffee\;time;;
     naive     'coffee\'           <- truncated
     spec      'coffee;time'       OK

  password 'a:b:c'
     payload   WIFI:T:WPA;S:cafe-wifi;P:a\:b\:c;;
     naive     'a\:b\:c'           <- backslashes kept
     spec      'a:b:c'             OK

  password 'back\slash'
     payload   WIFI:T:WPA;S:cafe-wifi;P:back\\slash;;
     naive     'back\\slash'       <- doubled
     spec      'back\slash'        OK

  password 'say"hi"'
     payload   WIFI:T:WPA;S:cafe-wifi;P:say\"hi\";;
     naive     'say\"hi\"'         <- backslashes kept
     spec      'say"hi"'           OK

The ; case is the dangerous one. It does not throw, it does not warn — it hands back coffee\ and the user gets an authentication failure with no clue why. The other three come back visibly wrong, which at least gets noticed.

One nuance from the same run: I escaped a comma in the SSID (cafe\,shop) and the naive parser still read the password correctly, because a comma never splits a ;-delimited string. The comma is in the escape set for spec compliance, not because ;-splitting needs it. Worth knowing if you are auditing someone else's encoder and wondering why their commas are bare.

Does it survive an actual QR code?

Escaping is only half the question. The other half is whether a real encoder and a real decoder agree once the payload has backslashes in it. So I baked each payload into an actual QR and read it back with OpenCV 5.0.0:

import cv2

def encode(text, ecc=cv2.QRCODE_ENCODER_CORRECT_LEVEL_M):
    p = cv2.QRCodeEncoder.Params()
    p.correction_level = ecc
    return cv2.QRCodeEncoder.create(p).encode(text)

def decode(img):
    # 1 pixel per module is too small for the detector: scale up and add a quiet zone
    big = cv2.resize(img, None, fx=8, fy=8, interpolation=cv2.INTER_NEAREST)
    big = cv2.copyMakeBorder(big, 40, 40, 40, 40, cv2.BORDER_CONSTANT, value=255)
    return cv2.QRCodeDetector().detectAndDecode(big)[0]

  'p@ssw0rd'     -> 33x33 modules (version 4)  round-trip matches
  'coffee;time'  -> 33x33 modules (version 4)  round-trip matches
  'a:b:c'        -> 33x33 modules (version 4)  round-trip matches
  'back\slash'   -> 33x33 modules (version 4)  round-trip matches

Byte-identical both ways. The backslashes are ordinary payload bytes as far as QR is concerned — nothing at the barcode layer touches them. Every failure I have seen with these codes lives in the string handling above it.

Two things that cost me time here, in case you run the same experiment: the encoder emits one pixel per module, so feeding its output straight to the detector fails — you have to scale up. And it needs a quiet zone; without the border the detector finds nothing.

The SSID that gets read as hex

This one is not about punctuation at all. If the SSID consists entirely of hex digits, it has to be wrapped in double quotes, or a reader is entitled to decode it as hex bytes rather than as text:

  SSID 'deadbeef'   all hex: True   -> needs quotes
       WIFI:T:WPA;S:"deadbeef";P:pw123456;;

  SSID '5060'       all hex: True   -> needs quotes
       WIFI:T:WPA;S:"5060";P:pw123456;;

  SSID 'cafe-5060'  all hex: False  -> fine as-is

5060 is the trap. A four-digit network name looks like the least exotic thing in the world, and a router that ships with the last four of its serial number as the SSID hits this by accident. cafe and deadbeef and abc123 are all in the same boat.

The check is two lines, and skipping it is the kind of bug that reproduces on exactly one customer's network.

What error correction costs

The other practical question: how much room does a long password actually take? I fixed a 9-character SSID and grew the password, encoding at each of the four error-correction levels. Numbers are the module count per side:

password	payload	L	M	Q	H
8 chars	35	33	33	37	41
12	39	33	33	37	41
16	43	33	37	37	41
20	47	33	37	41	45
32	59	37	37	41	49
63	90	41	45	53	57

Three things I took from this.

Short passwords are free. 8 and 12 characters produce an identical 33x33 grid at L and M. There is no size argument for a weaker password until you are past about 12 characters.

H is not a small ask. At a 63-character password, H needs 57 modules against L's 41 — the same physical square has modules 1.4x narrower on each side, which is exactly the thing that makes a print-out stop scanning from across a room. H buys you damage tolerance you mostly do not need on a laminated card taped to a wall.

The jump points are what matter, not the length. Growth is a staircase, and the steps land in different places per level: at L the grid holds at 33 all the way to a 20-character password and only steps up at 32, while at M it has already stepped up by 16. If you are sitting just past a step, three fewer characters can keep you a version smaller.

The encoder and parser, in full

SPECIAL = '\\;,:"'

def esc(s):
    return "".join("\\" + c if c in SPECIAL else c for c in s)

def is_hex(s):
    return bool(s) and all(c in "0123456789abcdefABCDEF" for c in s)

def build(ssid, pw, auth="WPA", hidden=False):
    field = esc(ssid)
    if is_hex(ssid):
        field = '"%s"' % field           # quote AFTER escaping - see below
    s = "WIFI:T:%s;S:%s;P:%s;" % (auth, field, esc(pw))
    if hidden:
        s += "H:true;"
    return s + ";"

def parse(payload):
    body = payload[len("WIFI:"):]
    fields, cur, i = [], [], 0
    while i < len(body):
        c = body[i]
        if c == "\\" and i + 1 < len(body):      # escaped: take the next char verbatim
            cur.append(body[i + 1]); i += 2; continue
        if c == ";":
            fields.append("".join(cur)); cur = []; i += 1; continue
        cur.append(c); i += 1
    if cur:
        fields.append("".join(cur))
    out = {}
    for f in fields:
        if f:
            k, _, v = f.partition(":")
            out[k] = v
    s = out.get("S", "")
    if len(s) >= 2 and s[0] == '"' and s[-1] == '"':
        out["S"] = s[1:-1]               # structural quotes, not part of the name
    return out

The parser is a character loop rather than a split, and that is the whole point. There is no regex that splits on unescaped ; without either lookbehind gymnastics or a bug.

The ordering trap I wrote for myself

My first version of build wrapped the SSID in quotes and then escaped the whole thing. That produces:

WIFI:T:WPA;S:\"deadbeef\";P:pw123456;;

The quotes are now escaped, which means they are literal " characters in the network name rather than the wrapper that says "read this as text, not hex". You get a payload that is valid, parses cleanly, and describes a network called "deadbeef" — with the quotes — which does not exist.

Escape first, wrap second. And on the way back out, strip the wrapper, or you hand the caller the same wrong name.

Note T:nopass for an open network, and that the trailing ;; is two semicolons — one ends the last field, one ends the payload.

What I did not test: actual phone cameras. Everything above is OpenCV encoding and decoding on one machine. Whether iOS Camera and the Android scanner agree on the all-hex SSID rule, or on a bare comma, I cannot tell you — I have no way to assert what a closed scanner does without testing every one of them. If you have a phone in hand and a minute, that is the gap I would most like filled in the comments.

The version for people who just want a code for the guest network, with the placement and safety bits: https://www.coding-now.com/en/guides/wifi-qr-code?utm_source=devto

That JSON error quotes what the server actually sent - and V8 cuts it at exactly 20 characters

코딩나우(하늘아래) — Wed, 30 Sep 2026 01:42:57 +0000

SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

Everyone knows what this means by now: the server sent HTML, your res.json() tried to parse it, the parser quit on the first character.

What I had never thought about is the quoted part. "<!DOCTYPE " is not a canned string V8 prints for HTML responses. It is the literal first ten characters of whatever you handed the parser. Which makes it a free, zero-effort peek at the response body — and it is more precise than I assumed.

Where the cut happens

I grew the input one character at a time on node v24.13.0 (V8 13.6.233.17):

for (let n = 8; n <= 24; n++) {
  const s = '<' + 'x'.repeat(n - 1);
  try { JSON.parse(s); } catch (e) { console.log(n, e.message); }
}

20 -> Unexpected token '<', "<xxxxxxxxxxxxxxxxxxx" is not valid JSON
21 -> Unexpected token '<', "<xxxxxxxxx"... is not valid JSON

20 characters or fewer: quoted whole. 21 or more: first ten, then .... One threshold, one prefix width.

Except the ten is not measured from the start of the string. It is measured from where parsing failed. Push the failure point inward with a value that starts out valid, and the quote grows to match:

for (const pad of [0, 1, 2, 5, 10]) {
  const s = '[' + ' '.repeat(pad) + 'o'.repeat(40);   // '[' opens an array, then junk
  try { JSON.parse(s); } catch (e) { console.log(e.message); }
}

fails at 1  -> "[oooooooooo"...            11 chars
fails at 2  -> "[ oooooooooo"...           12
fails at 3  -> "[  oooooooooo"...          13
fails at 6  -> "[     oooooooooo"...       16
fails at 11 -> "          oooooooooo"...   20  <- and now it slides

So the actual rule: the quoted window ends ten characters past the failure point and is capped at 20 characters wide, sliding forward once it hits the cap — and if the whole input fits in 20, you get all of it with no ....

For an HTML response none of that matters, because < fails at index 0 and the window is just the first ten. But it explains why the same error sometimes quotes eleven characters, or a run of text from the middle of the payload.

The message still gives you two free readings:

A trailing ... means the body was longer than 20 characters.
No ... means the quotes contain the entire response. Whatever is between them is everything the server sent.

The second one is the useful half. A short body is fully diagnosed from the error line alone, without opening DevTools.

The prefix is a fingerprint

Ten characters is enough to identify most things that show up where JSON should be. Each row below is the message that body actually produced:

Quoted prefix	Body started as	Typically
`"<!DOCTYPE "...`	an HTML document	404/500 page, login page, SPA `index.html`
`"<script sr"...`	HTML starting with `<script src=`	a script injected ahead of the page, a CDN or WAF interstitial
`"<?xml vers"...`	XML	`<Error><Code>` from object storage
`"Internal S"...`	one line of plain text	a proxy or gateway wrote the 500 itself
`"undefined"`	the string `"undefined"`	not the server — you passed a missing value
`"[object Object]"`	a stringified object	`JSON.parse` on something already parsed

The last two are worth internalising, because they print without any Unexpected token prefix — just "undefined" is not valid JSON. There is no token to name, so V8 skips that clause entirely. If you see that shape, stop looking at the network tab; nothing came off the wire.

Meanwhile, nobody honours your Accept header

I assumed a framework would at least try to answer JSON when you ask for it explicitly. It does not. Against this site's own Next.js 16 dev server:

curl -s -i -H "Accept: application/json" http://localhost:3000/api/nope

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8

<!DOCTYPE html><html lang="ko">    <- 26,283 bytes

26,283 bytes of rendered 404 page, in reply to a request that said it wanted JSON. Production, on Vercel, sent 20,672 bytes of the same thing. The Accept header changed nothing on either.

And `fetch` hands it to you as a success

Same call against five targets:

Target	status	ok	redirected	Content-Type	`res.json()`
missing API route, dev	404	false	false	text/html	SyntaxError
missing API route, prod	404	false	false	text/html	SyntaxError
http -> https redirect	404	false	true	text/html	SyntaxError
healthy JSON API	200	true	false	application/json	parsed
port with nothing on it	—	—	—	—	TypeError

In the first four rows fetch never threw. Every exception came from res.json(). So the message points at JSON while the actual evidence — status, Content-Type, redirected — was already sitting in your hand one line earlier.

Two of those rows deserve a note:

redirected: true is the login-page case. fetch follows redirects silently, so an expired session gets you a 200 with a login page in the body and no indication that you went somewhere else. res.url is the tell.

The last row is a different error entirely. No res exists. Node says TypeError: fetch failed, Chrome 152 says TypeError: Failed to fetch. Same situation, two strings, and only one of them is searchable alongside the other.

The wrapper

The fix is to look at the body before the parser does, and to put the body in the error when it is not JSON:

async function getJson(url) {
  const res = await fetch(url, { headers: { Accept: 'application/json' } });
  const type = res.headers.get('content-type') || '';
  const body = await res.text();          // text first, not json

  if (!type.includes('application/json')) {
    throw new Error(
      `Not JSON: ${res.status} ${type}\n` +
      `final URL: ${res.url}${res.redirected ? ' (redirected)' : ''}\n` +
      `first 200 chars: ${body.slice(0, 200)}`
    );
  }
  if (!res.ok) throw new Error(`${res.status}: ${body.slice(0, 200)}`);
  return JSON.parse(body);
}

res.text() first is the part that matters. The body is a stream you get once, so calling res.text() after res.json() already failed throws a second, less interesting error about the body being disturbed. Reverse the order and the body is still yours at the moment you need it.

The Content-Type check also catches the case an res.ok guard cannot: a dev server or proxy answering /api/... with index.html at status 200.

Python tells you nothing

Worth knowing if you move between the two. Four bodies that fail for four different reasons, through json.loads on python 3.11.9:

'<!DOCTYPE html>\n<html>'   -> Expecting value: line 1 column 1 (char 0)
''                          -> Expecting value: line 1 column 1 (char 0)
'Internal Server Error'     -> Expecting value: line 1 column 1 (char 0)
'undefined'                 -> Expecting value: line 1 column 1 (char 0)

Identical. char 0 says the first character was not the start of a value and stops there — it never says which character. The V8 message is doing real work that json does not, so on the Python side you have to print r.text[:200] yourself.

One more asymmetry in the same direction: urllib raises HTTPError on a 404, where fetch resolves happily. requests behaves like fetch and leaves r.ok to you.

The long version, with the five causes and how the headers separate them, is here: https://www.coding-now.com/en/guides/unexpected-token-doctype-json?utm_source=devto

If anyone knows whether that 20/10 window is stable across V8 versions, I would like to hear it — I only measured one, and I did not check SpiderMonkey or JavaScriptCore at all. And if you have seen a prefix that is not in the table above, post it; the fingerprint list is the part that gets more useful with more eyes.

Windows tar reads RAR and 7z - and silently writes a tar when you ask it for a RAR

코딩나우(하늘아래) — Tue, 29 Sep 2026 06:49:54 +0000

The tar.exe that ships in C:\Windows\System32 is libarchive, not GNU tar. That has two consequences worth knowing: it extracts formats you would not expect, and it fails at one of them in a way that returns exit code 0.

Measured on Windows 11 25H2, build 26200.9457.

It reads RAR and 7z

No install, no Store extension:

tar -tf archive.rar     # list without extracting
tar -xf archive.rar     # extract here
tar -xf archive.7z -C .\unpacked

A 1,731-byte RAR listed its entry and extracted to 4,585 bytes. A 909KB 7z extracted all 29 files. Both returned exit code 0.

The RAR tested carried the signature 52 61 72 21 1A 07 00 — RAR4. RAR5, which current WinRAR writes by default, was not tested here; I had no RAR5 sample. That is a gap in the measurement, not a known failure. tar -tf on your own file answers it in a second.

This is also why the "you need WinRAR" advice is mostly obsolete on Windows 11: the shell has had native RAR/7z handling since 23H2. You can see it in the registry — .rar lists ArchiveFolder among its handlers. On my machine the default was an installed archiver that had claimed the association years ago, which is the usual reason nobody notices.

Now the part that cost me time

Ask it to create a RAR:

tar -a -cf out.rar -C .\folder .
echo $LASTEXITCODE   # 0

Exit code 0. A file appears. It is not a RAR.

source folder   5,806,287 bytes
out.rar         5,837,312 bytes    <- larger than the input

Byte 257 of out.rar reads ustar. libarchive cannot write the RAR format — it is proprietary — so -a (auto-detect by extension) fell through to an uncompressed tar and used the name you asked for. No warning, no non-zero exit, and the only visible symptom is that your "compressed" archive grew.

If a build script does this, the artifact ships and fails at whoever tries to open it with a real RAR tool.

What it does write correctly

Verified by signature, not by extension:

Command	First bytes	Actual format	Size
`tar -a -cf out.7z`	`37 7A BC AF 27 1C`	7z	798,214
`tar -a -cf out.zip`	`50 4B 03 04`	zip	1,798,875
`tar -czf out.tar.gz`	`1F 8B`	gzip	1,788,453
`tar -a -cf out.rar`	`2E 2F 00 00` + `ustar` @257	plain tar	5,837,312

Same 5,806,287-byte source for all four.

Two things stand out. 7z came out 2.25x smaller than zip — 13.7% of the source versus 31.0%. And tar.gz landed within 1% of zip, which I did not expect; the deflate stream is doing nearly all the work in both, and the container overhead barely registers at this size.

Practical notes

Check the signature, not the extension, when a script produces an archive. Two bytes is enough for zip and gzip, six for 7z, and ustar at offset 257 catches a tar wearing someone else's name.

-a picks the format from the filename. That is convenient until the requested format is unwritable, at which point it degrades silently. Being explicit (-czf for tar.gz) removes the guessing.

Passwords are out of scope. There is no flag to supply one, so encrypted archives need a real archiver. Creating RAR and handling encrypted archives are the two jobs that still justify installing something — extraction is not one of them.

The version for people who just want the file open, with the Explorer route: https://www.coding-now.com/en/guides/open-rar-7z-windows?utm_source=devto

If anyone has a RAR5 sample handy, I would like to know whether tar -tf lists it on 25H2 — that is the one row of my table I could not fill in.

Windows encodes M4A and MP3 at the same bitrate, so the file sizes land 0.6% apart

코딩나우(하늘아래) — Tue, 29 Sep 2026 03:37:48 +0000

"Convert M4A to MP3 to save space" is advice you see everywhere. I measured it with the encoders that ship in Windows, and on the same source the two files came out 0.6% apart. Here is what is actually going on, and the PowerShell that does the conversion without installing anything.

The setup

One 10-second, 44.1kHz, 16-bit stereo WAV — 1,764,044 bytes, which Windows reports as 1,411,200 bps (44100 × 16 × 2, exactly CD rate). Everything below went through Windows.Media.Transcoding.MediaTranscoder on Windows 11, with sizes from the filesystem and bitrates from MusicProperties.

Same preset, same bitrate, same size

File	Bytes	Bitrate reported	Duration
source WAV	1,764,044	1,411,200 bps	10.00s
M4A `CreateM4a("High")`	243,233	192,512 bps	10.01s
M4A `CreateM4a("Medium")`	162,994	128,448 bps	10.01s
M4A `CreateM4a("Low")`	122,926	96,392 bps	10.01s
MP3 `CreateMp3("High")`	241,775	192,000 bps	—

The High presets are 192kbps for both. That is the whole explanation for the size result: AAC may be the better codec at a given bitrate, but Windows' presets never give it a lower bitrate to prove that with. You get the same bits either way, and the 1,458-byte gap is container overhead.

So if you are converting M4A to MP3 to save space, you are doing work for nothing. The only good reason is that something downstream only accepts MP3 — an upload validator, a car stereo, a hardware player.

The round trip is worse than it looks

Converting that M4A onward to MP3 gave 239,471 bytes. Similar size, but the audio inside has now been through two lossy encoders. And going back the other way:

source WAV            1,764,044 bytes
  -> M4A (High)         243,233 bytes
  -> WAV again        1,921,106 bytes

The recovered WAV is larger than the original WAV. A lossless container makes the file big again; it does not make the discarded audio reappear. If you ever need this spelled out for a non-technical colleague, that line usually does it.

There is a subtler one. Windows reports the source WAV as 10.00s, the M4A as 10.01s, and the MP3 as 9.96s. Encoder delay and padding are not free, and the container's idea of duration drifts with each hop. If you are stitching converted clips together, that drift is where the click at the seam comes from.

The conversion, with nothing installed

Windows ships the encoders; PowerShell can reach them through WinRT.

Add-Type -AssemblyName System.Runtime.WindowsRuntime
$ms = [System.WindowsRuntimeSystemExtensions].GetMethods()
$op = ($ms | Where-Object { $_.Name -eq 'AsTask' -and $_.GetParameters().Count -eq 1 -and $_.GetParameters()[0].ParameterType.Name -like 'IAsyncOperation*' })[0]
$ap = ($ms | Where-Object { $_.Name -eq 'AsTask' -and $_.GetParameters().Count -eq 1 -and $_.GetParameters()[0].ParameterType.Name -like 'IAsyncActionWithProgress*' })[0]
function Wait-Op($o, $t) { $x = $op.MakeGenericMethod($t).Invoke($null, @($o)); $x.Wait(-1) | Out-Null; $x.Result }
function Wait-Act($a) { $x = $ap.MakeGenericMethod([double]).Invoke($null, @($a)); $x.Wait(-1) | Out-Null }

[Windows.Storage.StorageFile,   Windows.Storage, ContentType=WindowsRuntime] | Out-Null
[Windows.Storage.StorageFolder, Windows.Storage, ContentType=WindowsRuntime] | Out-Null
[Windows.Media.MediaProperties.MediaEncodingProfile, Windows.Media, ContentType=WindowsRuntime] | Out-Null
[Windows.Media.Transcoding.MediaTranscoder, Windows.Media, ContentType=WindowsRuntime] | Out-Null

$folderPath = "C:\Users\you\Music"
$folder  = Wait-Op ([Windows.Storage.StorageFolder]::GetFolderFromPathAsync($folderPath)) ([Windows.Storage.StorageFolder])
$profile = [Windows.Media.MediaProperties.MediaEncodingProfile]::CreateMp3("High")

Get-ChildItem "$folderPath\*.m4a" | ForEach-Object {
    $src  = Wait-Op ([Windows.Storage.StorageFile]::GetFileFromPathAsync($_.FullName)) ([Windows.Storage.StorageFile])
    $dst  = Wait-Op ($folder.CreateFileAsync([IO.Path]::ChangeExtension($_.Name, ".mp3"), 1)) ([Windows.Storage.StorageFile])
    $t    = New-Object Windows.Media.Transcoding.MediaTranscoder
    $prep = Wait-Op ($t.PrepareFileTranscodeAsync($src, $dst, $profile)) ([Windows.Media.Transcoding.PrepareTranscodeResult])
    if ($prep.CanTranscode) { Wait-Act ($prep.TranscodeAsync()); "$($_.Name) -> $($dst.Name)" }
    else { "$($_.Name): $($prep.FailureReason)" }
}

Three things worth knowing before you run it:

The Wait-Op / Wait-Act wrappers are the point, not boilerplate. Windows PowerShell 5.1 has no await, and these calls are asynchronous. Skip the wait and you measure a file that is still being written — that is how a ten-second clip first came out of this script as 4KB.

CanTranscode is where failures surface. It returns false for a missing codec and for DRM-protected files. Old iTunes purchases (.m4p) land here and cannot be converted this way.

Swap the profile, not the script. CreateM4a, CreateWav and CreateMp3 all take the same "High" | "Medium" | "Low", so the same loop covers every direction — which is how the table above was produced.

The part that surprises people

M4A is a container, not a codec. It is the audio-only sibling of .mp4, which is why renaming one to .mp4 often still plays — same internal structure, different extension. It is also why renaming solves nothing when something validates the format.

And on Windows specifically: there is no Store extension to install. Unlike HEIC, M4A plays out of the box. When a double-click does nothing, the format is not the problem — no program is associated with the extension.

The version written for people who just received a voice memo they cannot open: https://www.coding-now.com/en/guides/m4a-to-mp3?utm_source=devto

Curious whether other platforms' presets pin AAC and MP3 to the same bitrate the way Windows does — if ffmpeg defaults differ on your setup, I would like to see the numbers.

Resize, format, quality: I measured all three image-size levers and one wins by 10x

코딩나우(하늘아래) — Mon, 28 Sep 2026 06:30:20 +0000

There are exactly three ways to make an image file smaller: change its dimensions, change its format, change its quality. Everyone knows this. What is less obvious is how unevenly they pay off — so I measured all three on the same photo instead of guessing.

Source: a 6400x4000 photograph, C:\Windows\Web\Screen\img102.jpg, 1,389,605 bytes as shipped. Everything below is Pillow 12.3.0 on Windows 11. PSNR is measured against the decoded source, so higher is closer to it.

Lever 1: format

Same pixels, same dimensions, different container.

Format	Bytes	vs PNG	PSNR (dB)
PNG (lossless)	7,058,497	100%	—
JPEG q100	4,228,908	59.9%	55.7
JPEG q90	1,358,048	19.2%	49.6
JPEG q80	992,596	14.1%	46.5
JPEG q70	746,185	10.6%	44.9
WebP q90	745,952	10.6%	47.1
WebP q80	321,938	4.6%	44.9
WebP q70	227,010	3.2%	43.9

Two rows in there are the whole argument for WebP:

JPEG q70   746,185 bytes   44.9 dB
WebP q80   321,938 bytes   44.9 dB

Identical PSNR, 2.3x smaller. Not "WebP is roughly 25-30% better" — on this photo, at matched measured quality, it is less than half the size. Pick the WebP row by PSNR rather than by quality number, because the quality scales are not the same scale.

Note the PNG row too. Storing an already-lossy photo losslessly costs 7MB to preserve JPEG artifacts perfectly. PNG is the right container for screenshots, logos and anything with text edges — not for photographs.

Lever 2: the quality slider

Where does it stop paying? Same source, JPEG only:

Quality	Bytes	Change	PSNR (dB)
100	4,228,908	—	55.7
95	1,953,547	−54%	51.5
90	1,358,048	−30%	49.6
85	1,173,332	−14%	47.7
80	992,596	−15%	46.5
70	746,185	−25%	44.9
60	641,501	−14%	43.2
50	596,403	−7%	42.8

Going 100 → 90 throws away 68% of the bytes and 6 dB. Going 60 → 50 throws away 7% of the bytes for another 0.4 dB. The bottom of the slider is where you pay in quality and stop being paid in bytes — the savings are already gone by the time you get there.

Lever 3: dimensions — this is the one that wins

Width	Pixels	JPEG q80	WebP q80
6400	25,600,000	992,596	321,938
3200	6,400,000	250,737	97,554
1600	1,600,000	74,902	30,510
1000	625,000	35,108	14,246
800	400,000	24,407	9,960

Halving the width quarters the pixel count, and the bytes roughly follow:

6400 -> 3200   992,596 -> 250,737   (25% of previous)
3200 -> 1600   250,737 ->  74,902   (30%)
1600 ->  800    74,902 ->  24,407   (33%)

Not exactly 25% each time, and the drift is in a consistent direction: the smaller the image, the less it shrinks per halving. Downscaling averages neighbouring pixels, so fine detail turns into per-pixel variation the encoder can no longer predict away — entropy per pixel goes up as pixel count goes down.

Put the levers together and the format argument stops looking important:

6400px PNG          7,058,497 bytes
1600px WebP q80        30,510 bytes     231x smaller

Resizing did most of that. The best format trick available at full size (PNG → WebP q80) was a 22x cut; resizing to 1600px on top of it took another 10x. If your pipeline compresses hard but serves camera-resolution images, you are optimising the small lever.

What this means in a pipeline

Resize first, then encode. Encoding a 25-megapixel image to throw the pixels away afterwards wastes both CPU and bytes.

Choose a target width from the layout, not from the source. A 1600px-wide image is enough for a 800px content column at 2x DPR. Everything past that is invisible.

Compare formats at matched PSNR, not matched quality numbers. quality=80 means different things to different encoders, which is exactly how "WebP saves 25%" becomes folklore instead of measurement.

Keep the original. Every number above is one-way. Re-encoding an already-compressed image compounds artifacts.

Reproducing this is about ten lines:

import io
from PIL import Image

src = Image.open("photo.jpg").convert("RGB")

def nbytes(img, fmt, **kw):
    buf = io.BytesIO()
    img.save(buf, fmt, **kw)
    return buf.tell()

for width in (6400, 3200, 1600, 800):
    h = round(src.size[1] * width / src.size[0])
    im = src if width == src.size[0] else src.resize((width, h), Image.LANCZOS)
    print(width, nbytes(im, "JPEG", quality=80), nbytes(im, "WEBP", quality=80))

The version for people who just want their photo to fit in an email, with the per-use-case settings: https://www.coding-now.com/en/guides/reduce-image-file-size?utm_source=devto

Curious what the matched-PSNR gap looks like on your images — the 2.3x here is one photo, and photos with large flat areas should favour WebP even harder.

The browser has no MP3 encoder, so a client-side audio trimmer writes WAV by hand

코딩나우(하늘아래) — Wed, 23 Sep 2026 07:29:39 +0000

I wanted a trimmer that cuts a clip out of a song without uploading the file anywhere. Decoding is easy — decodeAudioData takes an ArrayBuffer of almost any format the browser can play and hands back a Float32 AudioBuffer. Getting audio back out is where the platform stops helping.

MediaRecorder will not give you MP3 (or WAV)

I checked what Chrome 152 actually admits to:

const types = ['audio/mpeg', 'audio/mp3', 'audio/wav', 'audio/aac',
               'audio/ogg;codecs=opus', 'audio/webm;codecs=opus',
               'audio/mp4;codecs=mp4a.40.2'];
Object.fromEntries(types.map(t => [t, MediaRecorder.isTypeSupported(t)]));

audio/mpeg                 false
audio/mp3                  false
audio/wav                  false
audio/aac                  false
audio/ogg;codecs=opus      false
audio/webm;codecs=opus     true
audio/mp4;codecs=mp4a.40.2 true

So the only containers on offer are WebM/Opus and MP4/AAC — neither of which is what someone expects to receive when they asked to "cut an MP3". MP3 output means shipping an encoder: lamejs, or ffmpeg.wasm at 25MB+. For a tool whose entire pitch is "nothing is uploaded and nothing is installed", that is a lot of weight for a format conversion nobody asked for.

So you write the WAV header yourself

It's 44 bytes. This is the whole encoder from the trimmer I run:

function encodeWAV(buffer, startSample, endSample) {
  const numCh = buffer.numberOfChannels;
  const len = endSample - startSample;
  const sampleRate = buffer.sampleRate;
  const blockAlign = numCh * 2;
  const dataSize = len * blockAlign;
  const ab = new ArrayBuffer(44 + dataSize);
  const view = new DataView(ab);

  writeString(view, 0, "RIFF");
  view.setUint32(4, 36 + dataSize, true);
  writeString(view, 8, "WAVE");
  writeString(view, 12, "fmt ");
  view.setUint32(16, 16, true);
  view.setUint16(20, 1, true);            // PCM
  view.setUint16(22, numCh, true);
  view.setUint32(24, sampleRate, true);
  view.setUint32(28, sampleRate * blockAlign, true);
  view.setUint16(32, blockAlign, true);
  view.setUint16(34, 16, true);           // bits per sample
  writeString(view, 36, "data");
  view.setUint32(40, dataSize, true);
  // then interleave the channels as 16-bit LE from offset 44
}

Two details that matter more than they look:

Slice by sample index, not by seconds. The selection times become indices once — Math.floor(selStart * sr) and Math.floor(selEnd * sr), clamped to buffer.length — and everything downstream counts samples. Carrying seconds around and converting in two places is how you end up a sample off on one edge, which is audible as a click when a ringtone loops.

Use buffer.sampleRate, not the AudioContext's. On the machine I tested, new AudioContext().sampleRate is 48000 while a typical MP3 decodes at 44100. If you render the selection through an AudioContext (or an OfflineAudioContext created with the context's rate) you silently resample the whole clip for no reason. Read the samples straight out of the decoded buffer and copy them.

The file size nobody expects

PCM is uncompressed, so the arithmetic is the file:

44 + 44100 × 30 × 2ch × 2bytes = 5,292,044

I generated exactly that clip to check, and the file is 5,292,044 bytes — 5.0 MB for 30 seconds. The same 30 seconds as a 192kbps MP3 is about 0.7 MB. Users notice this the moment they try to move the file to a phone, so it's worth saying out loud in the UI rather than letting them discover it in a transfer dialog.

Where the format actually bites: ringtones

This is the use case that sends people to an audio trimmer in the first place, and the platform rules are asymmetric:

	What it accepts
Android	MP3, WAV (PCM), AAC/M4A, OGG, FLAC — per the platform's supported-formats table, so the WAV works as-is
iOS	goes through GarageBand, and Apple's documentation caps ringtones at 30 seconds

So on Android the raw WAV is fine and the only complaint is the 5MB. On iOS the format matters less than the length — and if the clip is longer, the export offers to shorten it for you, choosing the part it keeps. Which means the length constraint belongs in the trimmer, not in the phone: let people type exact start/end times and show the selection length while they drag.

That last point is the actual design lesson here. The encoder question (MediaRecorder versus a hand-written header) has one answer and you implement it once. The 30 seconds is what people get wrong every time, and only the UI can prevent it.

The non-developer walkthrough — cutting the clip, moving it, and the GarageBand and Files-app steps on each platform: https://www.coding-now.com/en/guides/make-ringtone-from-mp3?utm_source=devto

Has anyone shipped lamejs in production for this? I'd like to know what the bundle cost looked like in practice.

Windows can decode (and encode) HEIC without ImageMagick - and the browser ships no decoder

코딩나우(하늘아래) — Wed, 23 Sep 2026 04:23:43 +0000

Someone hands you a folder of iPhone photos, every file is .heic, and the form you need to upload them to wants JPG. The usual advice is "install ImageMagick" or "use this website". Neither is necessary on Windows, and the website advice hides something worth knowing about browsers.

Renaming is not converting (the 10-second check)

$ head -c 16 photo.heic | xxd
00000000: 0000 0020 6674 7970 6865 6963  ... ftypheic

Copy it to photo.jpg and those bytes don't move. Windows agrees about what it really is:

Add-Type -AssemblyName PresentationCore
$d = [System.Windows.Media.Imaging.BitmapDecoder]::Create([Uri]"C:\tmp\renamed.jpg", 'None', 'OnLoad')
$d.CodecInfo.FriendlyName   # -> Microsoft HEIF Decoder

Viewers sniff content, so the renamed file opens fine — right up until something validates the format.

The no-install route: WIC from PowerShell

Windows has had a HEIF codec since the Store extensions shipped, and WIC exposes it to .NET, so a whole folder is a loop:

Add-Type -AssemblyName PresentationCore

Get-ChildItem "C:\Users\you\Pictures\*.heic" | ForEach-Object {
    $f = [System.Windows.Media.Imaging.BitmapDecoder]::Create([Uri]$_.FullName, 'None', 'OnLoad').Frames[0]
    $e = New-Object System.Windows.Media.Imaging.JpegBitmapEncoder
    $e.QualityLevel = 90
    $e.Frames.Add($f)
    $o = [System.IO.File]::Create([IO.Path]::ChangeExtension($_.FullName, '.jpg'))
    $e.Save($o); $o.Close()
}

On my machine (Windows 11 25H2, build 26200.9457) that reported Microsoft HEIF Decoder, handed back a Bgr32 frame, and turned a 75,897-byte HEIC into a 59,241-byte quality-90 JPEG.

Two Store packages matter here: Microsoft.HEIFImageExtension (1.2.48 here) is the free one, and because the picture inside a HEIC is HEVC-compressed, some machines also need Microsoft.HEVCVideoExtension (2.5.33 here), which is a paid Store item unless your OEM shipped it. Check what you have:

Get-AppxPackage | Where-Object { $_.Name -match "HEIF|HEVC" } | Select-Object Name, Version

Bonus: Windows will also write HEIC

WPF has no HEIF encoder class, but WinRT does, and PowerShell can reach it. This is how I produced a real .heic to test against without owning an iPhone:

Add-Type -AssemblyName System.Runtime.WindowsRuntime
# ... AsTask/Await helpers omitted ...
$encId   = [Windows.Graphics.Imaging.BitmapEncoder]::HeifEncoderId
$encoder = AwaitOp ([Windows.Graphics.Imaging.BitmapEncoder]::CreateAsync($encId, $dstStream)) ([Windows.Graphics.Imaging.BitmapEncoder])
$encoder.SetSoftwareBitmap($bitmap)
AwaitAct ($encoder.FlushAsync())

A 1000x380 PNG came back out as a 75,897-byte .heic whose first bytes were ftypheic. Useful for fixtures.

The part that surprised me: browsers ship no HEIC decoder

No browser decodes HEIC on its own. In Chrome 152:

img.src = "test-photo.heic";
// img.naturalWidth === 0, img.complete === true

await createImageBitmap(await (await fetch("test-photo.heic")).blob());
// InvalidStateError: The source image could not be decoded.

Correction (2026-09-28): a reader on r/PowerShell pointed out that this measures the absence of a built-in decoder, not an impossibility — libheif compiled to WebAssembly decodes HEIC client-side, and heic2any / libheif-js are exactly that (2.6MB and 8.4MB unpacked). The reason converter sites upload is that download cost, not a browser limitation. Corrected here and in the original article.

drawImage on that element throws InvalidStateError too. So a site that converts HEIC either ships its own decoder or uploads your file to a server, and in practice nearly all of them upload. If the photos are of people or documents, that matters.

(For contrast, the same page loaded a PNG at 1000x380 without complaint, so this is about the format, not the page.)

Python: Pillow alone won't open it

>>> Image.open("test-photo.heic")
UnidentifiedImageError: cannot identify image file 'test-photo.heic'

You need the plugin that registers the opener:

import pillow_heif
from PIL import Image
from pathlib import Path

pillow_heif.register_heif_opener()

for src in Path(".").glob("*.heic"):
    Image.open(src).convert("RGB").save(src.with_suffix(".jpg"), quality=90)

That is the portable option — and the one to pick if you need EXIF handling or transparency rules you control, rather than whatever WIC's default frame gives you.

Quick reference

Need	Use
A folder, nothing installed, Windows	PowerShell + WIC
Cross-platform or in a pipeline	Pillow + `pillow-heif`
A test fixture, no iPhone	WinRT `HeifEncoderId`
Client-side in a browser	Only with a bundled WASM decoder (heic2any 2.6MB, libheif-js 8.4MB)
Photos of people or documents	Anything except an upload-based site

One more thing worth setting expectations on: the JPEG is usually bigger than the HEIC, because HEIC is the more efficient format. Converting "to save space" is backwards; resize instead.

Everything above was measured on Windows 11 25H2 with the HEIF and HEVC extensions installed — the codec name, the frame format, the byte counts, the Chrome errors and the Pillow failure are all from that run, not from memory.

The non-developer version, including the iPhone setting that stops HEIC files appearing in the first place: https://www.coding-now.com/en/guides/heic-to-jpg?utm_source=devto

Has anyone found a shipping browser that decodes HEIC, or a flag that enables it?

Converting WebP to JPG on Windows with no dependencies (and the alpha channel gotcha)

코딩나우(하늘아래) — Wed, 23 Sep 2026 01:53:39 +0000

Someone sends you a folder of .webp files and the upload form only takes JPG. You don't need ImageMagick for this: Windows has shipped a WebP decoder since 1809 (as the Store-delivered Microsoft.WebpImageExtension), and WIC exposes it to PowerShell. But the built-in path has two sharp edges I only found by testing them.

First: renaming is not converting

$ head -c 16 photo.webp | xxd
00000000: 5249 4646 4e0a 0000 5745 4250 5650 3820  RIFF....WEBPVP8

Rename it to photo.jpg and those bytes don't change. Most viewers sniff the content and open it anyway, which is exactly why people think the rename worked - until something that actually validates the format rejects it. Python agrees about what it really is:

>>> Image.open("renamed.jpg").format
'WEBP'

The no-install route: WIC via PowerShell

Add-Type -AssemblyName PresentationCore

$src   = "C:\Pictures\image.webp"
$frame = [System.Windows.Media.Imaging.BitmapDecoder]::Create([Uri]$src, 'None', 'OnLoad').Frames[0]
$enc   = New-Object System.Windows.Media.Imaging.JpegBitmapEncoder
$enc.QualityLevel = 90
$enc.Frames.Add($frame)
$out = [System.IO.File]::Create([IO.Path]::ChangeExtension($src, '.jpg'))
$enc.Save($out); $out.Close()

BitmapDecoder.Create picks the codec by content, and on a machine with the WebP extension you can confirm which one it chose:

$dec = [System.Windows.Media.Imaging.BitmapDecoder]::Create([Uri]$src, 'None', 'OnLoad')
$dec.CodecInfo.FriendlyName   # -> Microsoft Webp Decoder

A whole folder is the same thing in a loop:

Add-Type -AssemblyName PresentationCore

Get-ChildItem "C:\Pictures\*.webp" | ForEach-Object {
    $f = [System.Windows.Media.Imaging.BitmapDecoder]::Create([Uri]$_.FullName, 'None', 'OnLoad').Frames[0]
    $e = New-Object System.Windows.Media.Imaging.JpegBitmapEncoder
    $e.QualityLevel = 90
    $e.Frames.Add($f)
    $o = [System.IO.File]::Create([IO.Path]::ChangeExtension($_.FullName, '.jpg'))
    $e.Save($o); $o.Close()
}

Gotcha 1: the alpha channel is gone

This is the part worth knowing before you run it over a folder of logos. The frame that comes back from the Microsoft WebP decoder is Bgr32 - no alpha. Transparent pixels arrive black, and because the data is already flattened, switching to PngBitmapEncoder doesn't save you:

$f.Format              # -> Bgr32
# transparent WebP -> PNG, then inspect the corner pixel:
#   (0, 0, 0, 255)     # opaque black, not transparent

Pillow reads the same file as RGBA, so if transparency matters, do it in Python and decide what goes behind it:

from PIL import Image
from pathlib import Path

for src in Path(".").glob("*.webp"):
    im = Image.open(src)
    if im.mode in ("RGBA", "LA", "P"):       # composite onto white instead of black
        im = im.convert("RGBA")
        bg = Image.new("RGB", im.size, (255, 255, 255))
        bg.paste(im, mask=im.split()[3])
        im = bg
    im.convert("RGB").save(src.with_suffix(".jpg"), quality=90)

Gotcha 2: animated WebP silently loses everything after frame 1

The decoder does expose the frames - $dec.Frames.Count returned 4 for my test file, and Pillow reported n_frames = 4 for the same one. But Frames[0] is what the snippet above encodes, and JPEG has nowhere to put the rest. If the motion matters, GIF is two lines:

Image.open("anim.webp").save("anim.gif", save_all=True, loop=0)

And it gets bigger

WebP -> JPG is a re-encode of already-lossy data, so you pay twice: a little more generation loss, and usually a larger file. My 2.6 KB test WebP became 7.4 KB as a quality-90 JPEG. That tracks with Google's own numbers - lossy WebP is 25-34% smaller than JPEG at equivalent SSIM, lossless is 26% smaller than PNG - so converting "to save space" is backwards. Keep the original, and if size is the goal, resize instead of re-encoding.

Quick reference

Need	Use
One or two files, no install	Any browser-based converter that runs client-side
A folder, nothing installed	PowerShell + WIC (above)
Transparency preserved or flattened your way	Pillow
Animation kept	Pillow -> GIF

Everything above was run on Windows 11 with Microsoft.WebpImageExtension 1.2.31: the codec name, the Bgr32 frame format, the black corner pixel, the frame counts and the file sizes are measured, not assumed.

Longer version with the non-developer paths (Paint, Photos, a drag-and-drop converter that doesn't upload): https://www.coding-now.com/en/guides/webp-to-jpg?utm_source=devto

Has the alpha-drop bitten anyone else, or is there a WIC flag I missed?

Transparent PNGs: the 3 background-removal algorithms, why JPG can't do it, and the color-key gotcha

코딩나우(하늘아래) — Tue, 22 Sep 2026 01:39:12 +0000

Every "make this background transparent" tool is doing one of three things under the hood, and picking the wrong one for your picture is why a logo comes back with a hole in it, or the background is only half gone.

Transparency lives in the alpha channel

A pixel needs a fourth value beyond R, G, B: alpha, how see-through it is. Only formats that define an alpha channel can store it - PNG and WebP per-pixel, GIF as one fully-transparent color, never JPEG.

This isn't an implementation detail, it's in the spec. The HTML Living Standard says it outright for canvas export:

For image types that do not support an alpha component, the serialized image must be the bitmap image composited onto an opaque black background using the source-over compositing operator.

So canvas.toBlob(cb, 'image/jpeg') on a transparent canvas doesn't warn you, it silently paints black behind everything and hands you that. Pillow is less quiet about it - trying to save an RGBA image as JPEG raises OSError: cannot write mode RGBA as JPEG outright.

The three removal methods

AI subject detection - segments the main subject (person, product, animal) from everything else. Handles busy backgrounds, one click, but check fine edges (hair, glass) before you trust it. This is what Windows 11 Paint's Remove Background button and the Photos app do (Paint since the update Microsoft announced in Sept 2023, version 11.2306.30).

Connected area (flood fill / magic wand) - starts at a point you click and grows outward through similar, touching colors. GIMP's Fuzzy Select and macOS Preview's Instant Alpha both work this way. If the background is split into several disconnected regions by the subject, you click each region.

Color key - removes every pixel close to one chosen color, anywhere in the image. GIMP's Color to Alpha and PowerPoint's Set Transparent Color use this. Fast on a flat background, but if that color also shows up inside the subject, it goes transparent too.

I actually ran both non-AI methods on the same test image with Pillow - a blue circle logo on white, with a white square cut out in the middle (standing in for white text or a hole in a badge):

from PIL import Image, ImageDraw

# color key: kill every near-white pixel in the whole image
def color_key(im, key=(255, 255, 255), tol=30):
    im = im.convert("RGBA")
    px = im.load()
    for y in range(im.height):
        for x in range(im.width):
            r, g, b, a = px[x, y]
            if abs(r-key[0])<=tol and abs(g-key[1])<=tol and abs(b-key[2])<=tol:
                px[x, y] = (r, g, b, 0)
    return im

# connected area: flood fill from a known-background pixel
img = Image.open("logo.png").convert("RGBA")
ImageDraw.floodfill(img, (0, 0), (255, 255, 255, 0), thresh=30)

Color key made the inner white square transparent along with the background - a hole in the logo. Flood-fill from the corner only removed the background that's actually connected to it, leaving the inner square intact. Same tolerance, same image, opposite result, because they're answering different questions ("is this pixel near white?" vs "is this pixel reachable from here through near-white pixels?").

Rule of thumb: if the background color repeats inside the subject (white lettering on a white-background logo, a stamp with a white rim), color key gives you a hole - use flood fill or AI instead.

Doing it in bulk: rembg

For more than a couple of images, rembg (MIT license, Python 3.11-3.13) wraps several AI segmentation models behind one CLI:

pip install "rembg[cpu,cli]"

rembg i photo.jpg photo-cutout.png        # one file
rembg p input_folder output_folder        # a whole folder

It downloads the model on first use (cached under ~/.rembg/models/) and runs locally after that - nothing gets uploaded, which matters if the images aren't meant to leave your machine. The many online "remove.bg"-style tools are AI too, but the file goes to their server; fine for anything you'd publish anyway, not for scanned IDs or internal docs.

In the browser, without a server round-trip

If you're building this into a web page rather than a script, the color-key approach is a <canvas> pixel loop plus a distance check - no upload, no dependency:

function knockoutBackground(imageData, [kr, kg, kb], tolerance) {
  const d = imageData.data;
  for (let i = 0; i < d.length; i += 4) {
    const dist = Math.hypot(d[i]-kr, d[i+1]-kg, d[i+2]-kb);
    if (dist <= tolerance) d[i+3] = 0;
  }
  return imageData;
}

I use this approach (plus a small feather at the tolerance edge, to soften jagged outlines) in a small image converter tool - drop an image, eyedropper the background, adjust tolerance, export as PNG or WebP. Same color-key limitation applies: same-color pixels inside the subject go transparent too.

Full write-up with the side-by-side comparison image, Paint/Photos/PowerPoint/Preview steps, and a troubleshooting list: https://www.coding-now.com/en/guides/transparent-background-png?utm_source=devto

What's your go-to for batch background removal - rembg, something cloud-based, or hand-rolled?

No HyperTerminal on Windows 10/11? Free serial terminals and the 4 settings that matter

코딩나우(하늘아래) — Mon, 21 Sep 2026 06:59:17 +0000

Old equipment manuals still say "connect with HyperTerminal". On Windows 10 or 11 you won't find it: according to Hilgraeve, who wrote it and licensed it to Microsoft, it stopped shipping with Windows Vista and 7. Hilgraeve still sells HyperTerminal Private Edition ($69.99 as of September 2026, free trial), but free tools cover everything it did.

And no, Windows Terminal doesn't do serial. The GitHub request for it (microsoft/terminal #1280) has been open since 2019 and sits in the Icebox milestone.

1. Find the COM port

Device Manager -> Ports (COM & LPT). Unplug and replug the device; the entry that disappears and returns is yours. Or ask PowerShell:

[System.IO.Ports.SerialPort]::GetPortNames()
Get-PnpDevice -Class Ports -PresentOnly | Select-Object Status, FriendlyName

No port at all? Install the adapter chip's driver (CH340, CP210x, FTDI) and rule out a charge-only USB cable.

A big number like COM34 is harmless. On the PC I wrote this on, nine unplugged port devices still carried COM3 to COM20, while the board plugged in right now was on COM34. One catch: through the Win32 API, ports above 9 must be opened as \\.\COM10 (per the CreateFile docs), and some old programs never learned that.

2. The four settings

A serial line has no negotiation. Both ends assume the same rules, and if one differs the port still opens but the output is wrong.

Setting	Usual value	Symptom when wrong
Speed (baud)	9600 or 115200	A stream of unreadable characters
Data format	8N1	Only some characters come out wrong
Flow control	None	Sending stalls, or certain bytes vanish
Line ending	CR, LF or CR+LF	Commands get no reply

8N1 is 8 data bits, no parity, 1 stop bit, and it's what Arduino's Serial.begin() uses unless told otherwise. 7E1 (7 data bits, even parity) is the same length on the wire, which is why the speed can be right and some characters still turn into others. You'll meet it in things like Modbus ASCII.

PuTTY gotcha: its default serial flow control is XON/XOFF (per the defaults in its source). XON/XOFF sends 0x11 and 0x13 inside the data stream, so binary data containing those bytes gets eaten as flow control. Set Connection > Serial > Flow control to None unless your device really uses it.

3. The free programs

PuTTY - Session > Connection type: Serial, Serial line COM3, Speed. Data bits, parity and flow control live under Connection > Serial. Blank window? Press Enter a few times; some devices wait for the PC to speak first. Shortcut-friendly:

putty.exe -serial COM3 -sercfg 115200,8,n,1,N

The same options work with plink, so a Windows Terminal profile running plink.exe -serial COM3 -sercfg 115200,8,n,1,N turns a tab into a serial console (syntax per the PuTTY manual).

Tera Term - the closest thing to HyperTerminal, including XMODEM/YMODEM/ZMODEM/Kermit file transfer under File > Transfer. File > New connection > Serial, then Setup > Serial port for the line settings. You can't switch ports from that dialog while connected; disconnect first. 5.7.0 (Sept 2026) ships as an installer and as a plain ZIP.

RealTerm - open source, built for binary streams: hex and 8/16/32-bit views, timestamped capture. Port tab for speed and port.

CNTerminal (my tool, open source) - one 8 MB exe, no install: hex send/receive, an ASCII/hex converter, a preview of the exact bytes before sending, and a DTR toggle so an ESP32 doesn't reset on connect. Honest limit: it's fixed at 8N1 with no flow control, so use Tera Term for 7E1 gear or XMODEM.

4. Nothing installable? PowerShell

Windows PowerShell 5.1 ships with Windows and can use .NET's SerialPort directly:

$port = New-Object System.IO.Ports.SerialPort 'COM3', 115200, 'None', 8, 'One'
$port.ReadTimeout = 2000
$port.Open()
$port.WriteLine('AT')      # default line ending is LF
try { $port.ReadLine() } catch { 'no reply' }
$port.Close()

Defaults I checked: 9600, 8N1, no handshake, DTR and RTS both off. The open errors tell you what's wrong:

Access to the port 'COM3' is denied. - another program (Arduino serial monitor, another terminal, an upload tool) already has it open.
The port 'COM99' does not exist. - wrong number, or the device is unplugged.

mode COM3 in a command prompt prints the port's current speed, parity, data bits and DTR/RTS state.

Checklist when nothing shows up

Port not listed: driver, cable, another USB socket.
Port won't open: close whatever else holds it.
Garbled text: fix the speed; if only some characters are off, check 8N1 vs 7E1.
No reply: try CR, LF and CR+LF. Can't see what you type? The device doesn't echo; turn on local echo.
Board reboots on connect: that's the DTR/RTS auto-reset circuit on ESP32 and Arduino boards.

The full guide, with diagrams and a side-by-side comparison table:

Guide: https://www.coding-now.com/en/guides/hyperterminal-alternative?utm_source=devto
CNTerminal (free, no install): https://www.coding-now.com/en/cnterminal?utm_source=devto

What are you still using HyperTerminal-era manuals for?

Text to speech on Windows: the built-in voices, edge-tts, and why subtitle dubbing never fits

코딩나우(하늘아래) — Mon, 21 Sep 2026 01:02:18 +0000

Narration for a video, a spoken prompt in an app, a subtitle file turned into audio: all of it starts with getting text read out and saved to a file. Windows can do it with what's already installed, and the neural voices are a pip install away. Here's what each route costs you.

The voices already in Windows

Narrator and Edge's Read Aloud use the built-in speech engine, but neither will save what it reads. System.Speech will:

Add-Type -AssemblyName System.Speech
$s = New-Object System.Speech.Synthesis.SpeechSynthesizer

# What's available
$s.GetInstalledVoices() | ForEach-Object { $_.VoiceInfo.Name + " (" + $_.VoiceInfo.Culture + ")" }

$s.SelectVoice("Microsoft Zira Desktop")
$s.Rate = 0                      # -10 .. 10
$s.SetOutputToWaveFile("C:\temp\narration.wav")
$s.Speak((Get-Content "C:\temp\script.txt" -Raw -Encoding UTF8))
$s.Dispose()

No install, no network, and it writes a WAV. The delivery is unmistakably synthetic, so it suits prompts and beeps more than narration.

The gotcha: added voices that never show up

Add a voice under Settings > Time & language > Speech and it often doesn't appear in GetInstalledVoices(). The two generations of voices live in different registry hives:

# SAPI 5 - what System.Speech reads
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Speech\Voices\Tokens'

# OneCore - what Settings installs, and Narrator uses
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Speech_OneCore\Voices\Tokens'

On the Windows 11 (25H2) machine I checked, the SAPI hive had two voices and the OneCore hive had a third one that System.Speech could never select. If a voice you installed isn't in the list, this is why.

Neural voices from the command line

The voices Edge reads pages with are neural, and edge-tts drives them directly:

pip install edge-tts

# text -> MP3, with a matching .srt
edge-tts --text "Hello, world!" --write-media hello.mp3 --write-subtitles hello.srt

edge-tts --list-voices

# a script file, in a chosen voice
edge-tts --voice en-US-AriaNeural --file script.txt --write-media narration.mp3

edge-tts --rate=-50% --text "Hello, world!" --write-media slower.mp3
edge-tts --volume=-50% --text "Hello, world!" --write-media quieter.mp3
edge-tts --pitch=-50Hz --text "Hello, world!" --write-media lower.mp3

Options are from the project's README and CLI help. No API key, no account, and it writes MP3 rather than WAV, which matters once a batch of scripts piles up.

Dubbing subtitles: the lengths never match

A subtitle file states exactly how long each line is on screen. Read that line aloud and it is nearly always longer, because people skim subtitles while a synthesizer pronounces every syllable. Translate first and the gap widens.

cue  1  00:00:00,000 --> 00:00:03,500   (3.5s)   speech 3.2s   fits
cue  2  00:00:03,500 --> 00:00:07,000   (3.5s)   speech 4.6s   overruns into cue 3
cue  3  00:00:07,000 --> 00:00:12,000   (5.0s)   speech 4.4s   fits

What actually works:

Raise the rate. 10-20% faster still sounds natural.
Shorten the line. The narration doesn't have to match the subtitle word for word.
Merge two short cues into one sentence, which buys room either side.
If it has to be frame-accurate, cut per cue in an editor instead of fighting the timings.

Making something new rather than dubbing? Generate the narration first and cut the visuals to its length. Then nothing has to be squeezed.

The part people skip: licensing

ElevenLabs free tier: 10k credits a month, and no commercial licence on the free plan (paid starts at $6/month).
Naver Clova Dubbing free tier: monthly download and character limits, attribution required, ads and promotion need a paid plan.
The Edge neural voices have no quota through edge-tts, but they are Microsoft's service, so read the terms before shipping commercial work.

Figures are from September 2026 and these terms change often. "Free to generate, but not for monetised content" is a common combination, and it's the sort of thing that surfaces after the video is published.

The full version, with diagrams and a GUI option for people who don't want a terminal:

Guide: https://www.coding-now.com/en/guides/text-to-speech-mp3?utm_source=devto

Which route do you use for narration?

Windows Task Scheduler: why your scheduled task doesn't run (and what 0x41303 means)

코딩나우(하늘아래) — Fri, 18 Sep 2026 01:05:40 +0000

Creating a scheduled task in Windows takes five minutes. Then the time comes and nothing happens, or the program starts but you never see its window. Almost always it's one of a few defaults. The defaults below come from New-ScheduledTaskSettingsSet, and the result codes from Microsoft's Task Scheduler constants.

The four gates

A task has to get through four gates before anything visible happens:

1. Trigger           -> 0x41303: the task has not yet run
2. Conditions        -> on battery: doesn't start (default)
3. Security options  -> "whether user is logged on or not": no window
4. Action            -> 0x80070002: file not found, 0x1: the program's exit code

The Status and Last Run Result columns and the History tab tell you which gate stopped it. If History is empty, click Enable All Tasks History in the Actions pane. The same events are in Event Viewer under Applications and Services Logs > Microsoft > Windows > TaskScheduler > Operational.

No window: the security option

Run whether user is logged on or not runs the task in session 0, not on your desktop. A GUI program still starts but never shows up, and the task sits at 0x41301 (currently running). The default for an already running task is Do not start a new instance, so the next scheduled run is skipped too.

Programs you need to see: Run only when user is logged on, the default for Create Basic Task.
Scripts that need no window: whether logged on or not, which also stops the console window flashing. You have to save the password. Do not store password uses an S4U logon, which per Microsoft's docs has no access to the network or encrypted files, so skip it for backups to a NAS.

Only fails on a laptop: the power conditions

Two defaults on the Conditions tab:

Start the task only if the computer is on AC power: on
Stop if the computer switches to battery power: on

Clear both for tasks that should run on battery.

The other defaults

New-ScheduledTaskSettingsSet with no arguments shows them:

DisallowStartIfOnBatteries : True
StopIfGoingOnBatteries     : True
StartWhenAvailable         : False   <- runs missed while the PC was off are skipped
WakeToRun                  : False
ExecutionTimeLimit         : PT72H   <- stopped after 3 days
MultipleInstances          : IgnoreNew

The 3-day limit bites anything meant to stay open, like trading apps or servers. And an empty Start in (optional) makes the task run from C:\Windows\System32, so a program that loads its config from a relative path fails only when scheduled. For a batch file, cd /d "%~dp0" on the first line fixes it.

Reading Last Run Result

Code	Meaning
`0x0`	Success (exit code 0)
`0x41301`	The task is currently running
`0x41303`	The task has not yet run
`0x80070002`	The system cannot find the file specified
`0x800710E0`	The operator or administrator has refused the request
`0x1`, `0x2` ...	Usually the program's own exit code

0x41303 isn't a fault. Plenty of built-in tasks only run in specific situations: on the PC I checked, 76 of about 200 tasks showed it. For a batch file that ends with 0x1, append >> log.txt 2>&1 to its commands to see which one failed.

Creating it from the command line

schtasks has no Start in option, so if you need one, use PowerShell and fix the defaults while you're at it:

$action   = New-ScheduledTaskAction -Execute "C:\Tools\report.exe" -WorkingDirectory "C:\Tools"
$trigger  = New-ScheduledTaskTrigger -Daily -At 9am
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -ExecutionTimeLimit ([TimeSpan]::Zero)
Register-ScheduledTask -TaskName "Morning report" -Action $action -Trigger $trigger -Settings $settings

For quick one-liners schtasks is fine. Paths with spaces need an inner pair of single quotes:

schtasks /create /tn "Report" /tr "'C:\Program Files\Report\report.exe' --quiet" /sc daily /st 07:00
schtasks /run /tn "Report"
schtasks /query /tn "Report" /v /fo list

The full guide, with diagrams and the Create Basic Task walkthrough:

Guide: https://www.coding-now.com/en/guides/windows-task-scheduler?utm_source=devto

Which default has bitten you?

DEV Community: 코딩나우(하늘아래)

WiFi QR codes: the five escapes, the all-hex SSID trap, and what ECC level H costs you

Five characters have to be escaped

Does it survive an actual QR code?

The SSID that gets read as hex

What error correction costs

The encoder and parser, in full

The ordering trap I wrote for myself

That JSON error quotes what the server actually sent - and V8 cuts it at exactly 20 characters

Where the cut happens

The prefix is a fingerprint

Meanwhile, nobody honours your Accept header

And fetch hands it to you as a success

The wrapper

Python tells you nothing

Windows tar reads RAR and 7z - and silently writes a tar when you ask it for a RAR

It reads RAR and 7z

Now the part that cost me time

What it does write correctly

Practical notes

Windows encodes M4A and MP3 at the same bitrate, so the file sizes land 0.6% apart

The setup

Same preset, same bitrate, same size

The round trip is worse than it looks

The conversion, with nothing installed

The part that surprises people

Resize, format, quality: I measured all three image-size levers and one wins by 10x

Lever 1: format

Lever 2: the quality slider

Lever 3: dimensions — this is the one that wins

What this means in a pipeline

The browser has no MP3 encoder, so a client-side audio trimmer writes WAV by hand

MediaRecorder will not give you MP3 (or WAV)

So you write the WAV header yourself

The file size nobody expects

Where the format actually bites: ringtones

Windows can decode (and encode) HEIC without ImageMagick - and the browser ships no decoder

Renaming is not converting (the 10-second check)

The no-install route: WIC from PowerShell

Bonus: Windows will also write HEIC

The part that surprised me: browsers ship no HEIC decoder

Python: Pillow alone won't open it

Quick reference

Converting WebP to JPG on Windows with no dependencies (and the alpha channel gotcha)

First: renaming is not converting

The no-install route: WIC via PowerShell

Gotcha 1: the alpha channel is gone

Gotcha 2: animated WebP silently loses everything after frame 1

And it gets bigger

Quick reference

Transparent PNGs: the 3 background-removal algorithms, why JPG can't do it, and the color-key gotcha

Transparency lives in the alpha channel

The three removal methods

Doing it in bulk: rembg

In the browser, without a server round-trip

No HyperTerminal on Windows 10/11? Free serial terminals and the 4 settings that matter

1. Find the COM port

2. The four settings

3. The free programs

4. Nothing installable? PowerShell

Checklist when nothing shows up

Text to speech on Windows: the built-in voices, edge-tts, and why subtitle dubbing never fits

The voices already in Windows

The gotcha: added voices that never show up

Neural voices from the command line

Dubbing subtitles: the lengths never match

The part people skip: licensing

Windows Task Scheduler: why your scheduled task doesn't run (and what 0x41303 means)

The four gates

No window: the security option

Only fails on a laptop: the power conditions

The other defaults

Reading Last Run Result

Creating it from the command line

And `fetch` hands it to you as a success