DEV Community: Magill Anway

PLC inputs: match PNP sensors to sourcing cards and NPN to sinking cards

Magill Anway — Mon, 26 Oct 2026 01:24:46 +0000

A proximity sensor that "works on the bench" and then sits dark on the machine is usually a polarity mismatch, not a bad sensor. PLC digital inputs and sensor outputs have to agree on which side sources the current.

Sinking and sourcing

Current in a DC input circuit has a direction.

A sinking PLC input draws current into the input terminal. It pairs with an NPN (negative-switching) sensor. The sensor switches the load toward 0 V.
A sourcing PLC input pushes current out of the input terminal. It pairs with a PNP (positive-switching) sensor. The sensor switches the load toward +V.

The words are easy to swap because people describe either the sensor or the card. Read the card manual for sink versus source, then buy the sensor to match that card, not the other way around after the panel is built. A PNP sensor on a sinking-only input (or an NPN sensor on a sourcing-only input) does not give a reliable "1". It can look like an open wire.

Outputs follow the same split. A relay output tolerates mixed AC/DC loads and gives galvanic isolation, but it is slow and the contacts wear. A transistor output switches faster and lasts longer, but it is polarity- and voltage-specific: sink or source, and only the rated DC voltage. Do not treat "transistor output" as interchangeable with "relay output" on a contactor coil unless the datasheet says the transistor can carry that load.

What to write on the RFQ

Name the PLC input card and whether each channel is sinking, sourcing, or selectable.
Specify the sensor output as PNP or NPN to match that card, plus the supply voltage (commonly 24 V DC).
If the plant already standardized on one polarity, keep it. Mixed PNP and NPN spares are the usual commissioning fault.
For analog, keep this separate: 4-20 mA is a live-zero current loop (0 mA means a broken wire, not a process zero). It is not a PNP/NPN choice.

This is selection research, not a product offer. SpecForge is an industrial product specification encyclopedia for procurement engineers and automation integrators. It is not a manufacturer or a distributor, and it does not sell PLCs or sensors.

The I/O electricals chapter, including the sink/source pairing and the analog live-zero note, is in the SpecForge PLC selection guide:

https://www.sourcebyspec.com/encyclopedia/plc.html

How the same PNP/NPN output shows up on a proximity switch datasheet is in the proximity sensor guide:

https://www.sourcebyspec.com/encyclopedia/proximity-sensor.html

Verify the card and the sensor against the current manufacturer PDFs before you release the panel wiring.

Pressure transmitter accuracy: %span and %URL are not the same error

Magill Anway — Mon, 26 Oct 2026 01:18:49 +0000

Two pressure-transmitter datasheets can both print "±0.1%" and still describe very different errors. The percentage is only meaningful once you know what it is a percentage of.

A pressure transmitter is the field instrument that converts process pressure into a standardized output, usually 4-20 mA (sometimes with HART) or a digital fieldbus, for a PLC, DCS, or recorder. It is not a bare sensing cell. The electronics add temperature compensation, damping, engineering units, and the range you actually calibrate.

URL, span, and turndown

The Upper Range Limit (URL) is the model's maximum settable range. The calibrated span is the slice of that URL you order and use. Turndown (rangedown) is URL divided by calibrated span: 10:1, 100:1, and on some models 200:1.

Turning a wide-URL model down to a small span is convenient for spares, but it is not free. Datasheets state that a higher turndown raises the measured error. A model used near its URL and the same model turned down 100:1 are not the same installation.

What %span and %URL actually reference

%span (also written %FS, percent of full scale) is referenced to the full scale of the selected, calibrated range.
%URL is referenced to the model's maximum settable range, not to the range you turned it down to.

At the same printed percentage, %URL produces a larger real error on a small turned-down range, because the percentage is taken against a much bigger number.

Sketch, in engineering units, not a vendor claim: URL = 100 bar, calibrated span = 10 bar (turndown 10:1).

±0.1 %span is 0.01 bar at that span.
±0.1 %URL is 0.10 bar on the same installation.

The datasheet percentages looked identical. The loop error did not. Comparing a tight %span figure with a %URL figure, or with a "% of reading" flow specification, without converting them first will rank the wrong instrument.

Long-term stability lines have the same trap. One vendor may quote drift as a percent of span; another quotes percent of URL per year. Those lines are not interchangeable with the reference-accuracy line, and BFSL (best-fit straight line) is not the same method as a terminal-based accuracy statement.

A check before the RFQ

Write down the URL and the calibrated span you will actually buy.
Note whether each accuracy line is %span, %URL, or % of reading, and which method (BFSL or terminal) it uses.
Convert every line into engineering units at your span before you rank vendors.
Treat turndown as part of the error budget, not as a footnote.
Confirm the output the PLC expects (4-20 mA, HART, or a fieldbus) and the fault behavior (for example NAMUR NE 43 currents outside 3.8-20.5 mA) separately from the accuracy reference.

This note is selection research, not a product offer. SpecForge is an industrial product specification encyclopedia for procurement engineers, automation integrators, and metrology readers. It compares datasheet-level parameters for instruments such as pressure transmitters, PLCs, VFDs, sensors, pumps, and valves. It is not a manufacturer or a distributor, and it does not sell the devices discussed here.

The longer decoding of the %span versus %URL trap, with the selection order and the NAMUR NE 43 fault-current behavior, is in the SpecForge pressure transmitter guide:

https://www.sourcebyspec.com/encyclopedia/pressure-transmitter.html

Verify every value against the manufacturer's current PDF before procurement. A directory figure is a reading aid, not a substitute for the datasheet you will attach to the purchase order.

Compress a PDF Locally Before You Hit the Email Cap: A Privacy-First Size Checklist

Magill Anway — Tue, 29 Sep 2026 01:38:39 +0000

Compress a PDF Locally Before You Hit the Email Cap: A Privacy-First Size Checklist

Answer first: If a scanned contract, tax packet, or HR form is too large for email or a portal, shrink it on your machine before any “free compress PDF online” host sees the bytes. Size caps are a UX problem. Uploading sensitive pages to fix them is a privacy problem. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Teams still bounce 20 MB scan packs off Gmail or a government upload form, then paste the same file into the first Google result for “compress PDF.” That host briefly receives every page — medical, financial, or signed. The useful habit is not another brand name. It is: treat size reduction as part of the local prep, then send once.

Cloud compressors also leave a history of files you “temporarily” uploaded. Local compression cuts that trail without changing the UX of attaching a smaller PDF.

Pre-send size checklist (2 minutes)

Know the real cap. Email ~25 MB, many portals 2–10 MB. Measure the file before you hunt tools.
Prefer local compress over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample PDF. Pass = no multipart POST carrying your file to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If compression still finishes, upload-to-server architecture is off the table for that action.
Send the shrunk artifact once. Attach the compressed PDF — do not leave the original sitting in a cloud draft next to your passport scan.

A local compression workflow

Step 1 — Keep sensitive packets offline until ready

Do not open tax or medical PDFs in a random tab until you are ready to shrink the ones you will send.

Step 2 — Decide quality vs size

Image-heavy scans tolerate more loss. Text-heavy contracts need a lighter pass so pages stay readable.

Step 3 — Compress in the tab

Drop the file into a browser-local PDF compressor. Closing the tab should clear in-memory copies; the file you download is the artifact you send.

Step 4 — Share once

Skip the detour through a random “free compress PDF online” host for packets you would not email to a stranger.

One browser-local starting point

When you need an on-device PDF compressor without creating an account, this Compress PDF tool runs in the tab (files stay on your device):

https://www.lizecheng.net/pdf/compress-pdf/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260929&utm_content=compress-pdf

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
18 MB passport scan for a portal with 5 MB cap	Compress locally → send once
Multi-page receipt pack choking email	Compress locally; split if still huge
Deck export with huge embedded photos	Compress locally before Slack/email
Mixed public brochure + private annex	Two files; never upload the private annex

Closing

PDF size is a solved UX problem. The open question is whether the bytes leave your device on the way to the recipient. Prefer tools you can verify with Network + offline checks — and keep cloud compressors for files you would not mind a stranger viewing.

Strip PDF Metadata Locally Before You Share: A Privacy Checklist for Contracts and Scans

Magill Anway — Mon, 28 Sep 2026 01:44:51 +0000

Strip PDF Metadata Locally Before You Share: A Privacy Checklist for Contracts and Scans

Answer first: If a signed contract, medical scan, or HR packet still carries Author, Title, Producer, or Creator Tool fields from your laptop, edit that metadata on your machine before any cloud converter sees the file. Free "edit PDF online" sites are convenient — and they briefly receive every page you upload. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Teams still email "final" PDFs that quietly leak usernames, internal tool names, and prior revision titles in the Info dictionary. The useful takeaway is not another brand name — it is a habit: treat metadata as part of the document until you have stripped or rewritten the fields you mean to share, then send once.

Cloud editors also leave a history of files you "temporarily" uploaded. Local metadata edits cut that trail without changing the UX of attaching a clean PDF.

Pre-share checklist (2 minutes)

Know what Info shows. Author, Title, Subject, Keywords, Creator, Producer, creation/mod dates. Assume every field is hot until you inspect locally.
Prefer local edit over "upload then hope the host deletes it." Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools, Network, clear the log, try a non-sensitive sample PDF. Pass = no multipart POST carrying your file to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If metadata edit still finishes, upload-to-server architecture is off the table for that action.
Send the cleaned artifact once. Attach the edited PDF — do not leave the original with your username sitting in a cloud draft.

A local metadata workflow

Step 1 — Inspect offline if needed

Keep contracts offline until you are ready to clean the ones you will send.

Step 2 — Decide what must stay

Public titles can stay; laptop usernames and internal tool strings should not leave the device.

Step 3 — Edit in the tab

Drop the file into a browser-local PDF metadata editor. Closing the tab should clear in-memory copies; the file you download is the artifact you send.

Step 4 — Share once

Skip the detour through a random "free edit PDF online" host for packets you would not email to a stranger.

One browser-local starting point

When you need an on-device PDF metadata editor without creating an account, this PDF Metadata Editor runs in the tab (files stay on your device):

https://www.lizecheng.net/pdf/pdf-metadata-editor/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260928&utm_content=pdf-metadata

(That is the only product link in this post.)

What "good enough" looks like

Scenario	Local move
Contract with your Windows username as Author	Clear/rewrite Author locally, then send once
Scan whose Producer field names internal OCR	Strip Producer locally
Deck PDF with old Title from a prior client	Rewrite Title locally
Mixed public brochure + private annex	Two files; never upload the private annex

Closing

PDF metadata is a solved UX problem. The open question is whether the bytes leave your device on the way to the recipient. Prefer tools you can verify with Network + offline checks — and keep cloud editors for files you would not mind a stranger viewing.

Compress Screenshots Locally Before You Upload: A Privacy Checklist for Tickets and Chat

Magill Anway — Sun, 27 Sep 2026 01:41:47 +0000

Compress Screenshots Locally Before You Upload: A Privacy Checklist for Tickets and Chat

Answer first: If a support ticket, Slack thread, or bug report still carries a full-resolution dashboard screenshot (account IDs, staging URLs, customer emails in the chrome), compress it on your machine before any cloud media host sees the file. Free “compress image online” sites are convenient and they briefly receive every pixel you upload. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Teams still paste raw Retina captures “just in case.” The useful takeaway is not another brand name — it is a habit: treat the screenshot as sensitive until you have shrunk it to the size you mean to share, then attach once.

Cloud compressors also leave a history of files you “temporarily” uploaded. Local compress cuts that trail without changing the UX of attaching a readable image.

Pre-upload checklist (2 minutes)

Know what the chrome shows. Account numbers, prior chat names, staging URLs, badge scans. Assume every pixel is hot until you process locally.
Prefer local compress over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample PNG. Pass = no multipart POST carrying your file to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If compress still finishes, upload-to-server architecture is off the table for that action.
Send the smallest correct artifact. Attach the compressed image — do not leave the 8 MB original sitting in a cloud draft.

A local compress workflow

Step 1 — Capture offline if needed

Keep ticket screenshots offline until you are ready to shrink the ones you will paste.

Step 2 — Crop what you do not need

Note sidebar lists, earlier revisions, or ID scans that should never leave your device.

Step 3 — Compress in the tab

Drop the file into a browser-local image compressor. Closing the tab should clear in-memory copies; the file you download is the artifact you send.

Step 4 — Share once

Skip the detour through a random “free compress image online” host for screenshots you would not email to a stranger.

One browser-local starting point

When you need an on-device image compressor without creating an account, this Image Compressor runs in the tab (files stay on your device):

https://www.lizecheng.net/image/image-compressor/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260927&utm_content=image-compressor

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
8 MB Retina dashboard for a ticket	Compress locally → attach once
Slack paste with customer email in chrome	Crop + compress locally
Bug report with staging URL in the URL bar	Crop URL bar locally before share
Mixed public UI + private PII panel	Two files; never upload the private panel

Closing

Image compression is a solved UX problem. The open question is whether the bytes leave your device on the way to the recipient. Prefer tools you can verify with Network + offline checks — and keep cloud compressors for images you would not mind a stranger viewing.

Split PDFs Locally Before You Share: A Privacy Checklist for Contracts and Scans

Magill Anway — Sat, 26 Sep 2026 01:40:59 +0000

Split PDFs Locally Before You Share: A Privacy Checklist for Contracts and Scans

Answer first: If a signed PDF packet still contains pages you do not need to send (bank statements, earlier drafts, ID scans), split it on your machine before any cloud converter sees the file. Free “split PDF online” sites are convenient — and they briefly receive every page you upload. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Teams still forward entire multi-page packets “just in case.” The useful takeaway is not another brand name — it is a habit: treat the PDF as sensitive until you have extracted only the pages you mean to share, then attach once.

Cloud splitters also leave a history of files you temporarily uploaded. Local split cuts that trail without changing the UX of attaching a correctly sliced PDF.

Pre-share checklist (2 minutes)

Know what extra pages show. Account numbers, prior signatures, staging URLs, badge scans. Assume every page is hot until you process locally.
Prefer local split over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample PDF. Pass = no multipart POST carrying your file to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If split still finishes, upload-to-server architecture is off the table for that action.
Send the smallest correct artifact. Attach the sliced PDF — do not leave the full packet sitting in a cloud draft.

A local split workflow

Step 1 — Capture offline if needed

Keep contract packets offline until you are ready to extract the pages you will email.

Step 2 — Mark pages you do not need

Note cover sheets, earlier revisions, or ID scans that should never leave your device.

Step 3 — Split in the tab

Drop the file into a browser-local PDF splitter. Closing the tab should clear in-memory copies; the file you download is the artifact you send.

Step 4 — Share once

Skip the detour through a random “free split PDF online” host for documents you would not email to a stranger.

One browser-local starting point

When you need an on-device PDF splitter without creating an account, this Split PDF tool runs in the tab (files stay on your device):

https://www.lizecheng.net/pdf/split-pdf/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260926&utm_content=split-pdf

(That is the only product link in this post.)

What good enough” looks like

Scenario	Local move
12-page packet, only pages 3–5 needed	Split locally → email once
Client contract with earlier draft attached	Extract final pages locally
Scan batch with ID page in the middle	Remove ID page locally before share
Mixed public appendix + private annex	Two files; never upload the private annex

Closing

PDF splitting is a solved UX problem. The open question is whether the bytes leave your device on the way to the recipient. Prefer tools you can verify with Network + offline checks — and keep cloud splitters for documents you would not mind a stranger viewing.

Resize Images Locally Before WordPress Upload: A Privacy Checklist

Magill Anway — Fri, 25 Sep 2026 01:40:39 +0000

Step 2 — Crop what you do not need

Crop out sidebar nav or chat bubbles that leak context before you resize.

Step 3 — Resize in the tab

Drop the file into a browser-local image resizer. Closing the tab should clear in-memory copies; the file you download is the artifact you upload.

Step 4 — Upload once

Skip the detour through a random “free resize online” host for images you would not email to a stranger.

One browser-local starting point

When you need an on-device image resizer without creating an account, this Image Resizer runs in the tab (files stay on your device):

https://www.lizecheng.net/image/image-resizer/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260925&utm_content=image-resizer

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
Featured image with staging URL in corner	Crop + resize locally → upload once
Client UI bug report for WP post	Resize locally → attach
Marketing asset with emails visible	Redact + resize locally
Mixed public hero + private panel	Two files; never upload the private panel

Closing

Image sizing is a solved UX problem. The open question is whether the pixels leave your device on the way to your media library. Prefer tools you can verify with Network + offline checks — and keep cloud resizers for photos you would not mind a stranger viewing.

Compress Images Locally: A Privacy Checklist Before You Upload Screenshots

Magill Anway — Thu, 24 Sep 2026 01:50:06 +0000

Compress Images Locally: A Privacy Checklist Before You Upload Screenshots

Answer first: If a screenshot shows a customer name, a staging URL, or an internal dashboard, compress it on your machine before you drop it into a cloud image compressor. Free online compressors are convenient — and they briefly see every pixel you upload. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Support threads still treat free image compressors like a trash chute. The useful takeaway is not another brand name — it is a habit: treat the bitmap as sensitive until you have shrunk it locally, then attach or post once.

Cloud compressors also leave a history of files you “temporarily” uploaded for a Slack paste. Local compression cuts that trail without changing the UX of sharing a smaller PNG.

Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample image. Pass = no multipart POST carrying your file to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If compression still finishes, upload-to-server architecture is off the table for that action.
Share the smallest artifact. Attach the compressed PNG/JPEG — do not leave the original sitting in a cloud draft.

A local compress workflow

Step 1 — Capture offline if needed

Keep dashboard screenshots offline until you are ready to shrink them.

Step 2 — Trim what you do not need

Crop out sidebar nav or chat bubbles that leak context before you compress.

Step 3 — Compress in the tab

One browser-local starting point

When you need an on-device image compressor without creating an account, this Image Compressor runs in the tab (files stay on your device):

https://www.lizecheng.net/image/image-compressor/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260924&utm_content=image-compressor

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
Client UI bug report	Compress locally → attach PNG
Internal dashboard share	Crop + compress → share once
Marketing screenshot with emails	Redact + compress locally
Mixed public asset + private panel	Two files; never upload the private panel

Closing

Image compression is a solved UX problem. The open question is whether the pixels leave your device on the way. Prefer tools you can verify with Network + offline checks — and keep cloud compressors for photos you would not mind a stranger viewing.
Drop the file into a browser-local image compressor. Closing the tab should clear in-memory copies; the file you download is the artifact you send.

Step 4 — Share once

Skip the detour through a random “free compress online” host for images you would not email to a stranger.

Pre-share checklist (2 minutes)

Know what the image shows. Customer PII, internal URLs, badge scans, staging panels. Assume the pixels are hot until you process locally.
Prefer local compress over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.

Generate QR Codes Locally: A Privacy Checklist for Wi‑Fi, Events, and Offline Handouts

Magill Anway — Wed, 23 Sep 2026 01:52:50 +0000

Generate QR Codes Locally: A Privacy Checklist for Wi‑Fi, Events, and Offline Handouts

Answer first: If a QR encodes a Wi‑Fi password, a private event RSVP, or an internal URL, generate it on your machine before you paste that string into a cloud QR site. Free online generators are convenient — and they briefly see every payload you type. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Support threads still treat free QR generators like notepads. The useful takeaway is not another brand name — it is a habit: treat the payload as sensitive until you have rendered the code locally, then print or share once.

Cloud generators also leave a history of strings you typed for “temporary” event badges. Local rendering cuts that trail without changing the UX 3. Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample string. Pass = no multipart POST carrying your text to a third-party API.

Airplane-mode sanity check. After page assets load, go offline and retry. If QR still renders, upload-to-server architecture is off the table for that action.
Share the smallest artifact. Print or export the PNG/SVG — do not leave the raw password sitting in a cloud draft.

A local QR workflow

Step 1 — Draft the payload offline if needed

Keep Wi‑Fi credentials or staging URLs offline until you are ready to render.

Step 2 — Choose the right content type

Plain URL, Wi‑Fi (WIFI:T:WPA;S:...;P:...;;), or short text for a handout — nothing else.

Step 3 — Generate in the tab

One browser-local starting point

When you need an on-device QR generator without creating an account, this QR Code Generator runs in the tab (payload stays on your device):

https://www.lizecheng.net/seo/qr-code-generator/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260923&utm_content=qr-code

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
Guest Wi‑Fi card for visitors	Generate locally → print PNG
Private event RSVP QR	Render locally → embed in invite PDF
Staging URL for a demo booth	Generate → share once; keep URL offline otherwise
Mixed public landing + private PSK	Two codes; never paste the PSK into a cloud generator

Closing

QR generation is a solved UX problem. The open question is whether the payload leaves your device on the way. Prefer tools you can verify with Network + offline checks — and keep cloud generators for strings you would not mind a stranger reading.
Drop the string into a browser-local QR tool. Closing the tab should clear in-memory copies; the PNG you download is the artifact you print or embed.

Step 4 — Share once

Skip the detour through a random “free QR online” host for payloads you would not email to a stranger.
of scanning.

Pre-share checklist (2 minutes)

Know what the QR encodes. Wi‑Fi PSK, private RSVP links, staging URLs, tracking tokens. Assume the payload is hot until you render locally.
Prefer local generate over “paste then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.

Split PDFs Locally Before You Share: A Privacy Checklist for Contracts

Magill Anway — Tue, 22 Sep 2026 01:52:43 +0000

Split PDFs Locally Before You Share: A Privacy Checklist for Contracts

Answer first: If a PDF holds contracts, IDs, or customer data and you only need a few pages, extract those pages on your machine before you upload or email anything. Cloud “split PDF online” sites are convenient — and they briefly hold every page you upload. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Support threads still treat free online PDF splitters like notepads. The useful takeaway is not another brand name — it is a habit: treat the full document as sensitive until you have extracted only what you need locally, then share once.

Oversized multi-page scans also clog email and ticket systems. Splitting locally cuts size without sending the original off-device first.

Pre-share checklist (2 minutes)

Know what is in the full file. Cover pages, appendices, signatures, account numbers, internal URLs. Assume the whole PDF is hot until you extract.
Prefer local split over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample. Pass = no multipart POST carrying your PDF to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If split still works, upload-to-server architecture is off the table for that action.
Share the smallest artifact. Send the extracted pages — not the 40-page binder you started with.

A local split workflow

Step 1 — Open the source offline if needed

Keep the original offline if you still need full fidelity for archives.

Step 2 — Mark the pages you actually need

Page ranges for the counterparty, ticket, or form — nothing else.

Step 3 — Split in the tab

Drop the PDF into a browser-local splitter. Closing the tab should clear in-memory copies; the file you download is the artifact you share.

Step 4 — Share once

Skip the detour through a random “free split PDF online” host for documents you would not email to a stranger.

One browser-local starting point

When you need an on-device PDF splitter without creating an account, this Split PDF tool runs in the tab (files stay on your device):

https://www.lizecheng.net/pdf/split-pdf/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260922&utm_content=split-pdf

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
Counterparty needs pages 3–5 of a contract	Extract locally → email those pages
Ticket needs one scan page from a long PDF	Split locally → attach the page
Share a signature page only	Extract → share; keep the rest offline
Mixed sensitive + public appendix	Split locally; never upload the full binder

Closing

PDF split is a solved UX problem. The open question is whether the bytes leave your device on the way. Prefer tools you can verify with Network + offline checks — and keep cloud splitters for files you would not mind a stranger reading.

Compress Screenshots Before You Paste: A Local Checklist for Chat and Tickets

Magill Anway — Mon, 21 Sep 2026 01:50:18 +0000

Compress Screenshots Before You Paste: A Local Checklist for Chat and Tickets

Answer first: If a screenshot might show emails, IDs, dashboards, or customer data, shrink it on your machine before you paste it into Slack, Discord, or a ticket. Cloud compressors are convenient — and they briefly hold every pixel you upload. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Step 1 — Capture

Use your OS screenshot tool or browser capture. Keep the original offline if you still need full fidelity.

Step 2 — Crop PII

Remove chrome, unread badges, and anything outside the bug. Smaller canvas = smaller file and less accidental disclosure.

Step 3 — Compress in the tab

Drop the cropped file into a browser-local compressor. Closing the tab should clear in-memory copies; the file you download is the artifact you paste.

Step 4 — Paste once

Skip the detour through a random “free compress online” host for shots you would not email to a stranger.

One browser-local starting point

When you need an on-device compressor without creating an account, this Image Compressor runs in the tab (files stay on your device):

https://www.lizecheng.net/image/image-compressor/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260921&utm_content=image-compressor

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
Bug report with a huge Retina PNG	Crop → compress locally → paste
Screenshot of a customer dashboard	Crop PII → compress → ticket
Share a UI mock in chat	Compress first; do not upload the raw capture
Mixed JPEG/PNG batch	Compress each locally; skip cloud batch uploaders

Closing

Image compression is a solved UX problem. The open question is whether the bytes leave your device on the way. Prefer tools you can verify with Network + offline checks — and keep cloud compressors for files you would not mind a stranger viewing.
Support threads still treat “free online image compressor” sites like notepads. The useful takeaway is not another brand name — it is a habit: treat the capture as sensitive until you have cropped and compressed it locally, then paste once.

Oversized PNGs from Retina displays also clog channels and tickets. Compressing locally cuts size without sending the original off-device first.

Pre-paste checklist (2 minutes)

Know what is visible. Browser chrome, email addresses, account IDs, internal URLs, chat sidebars. Assume the whole frame is hot until cropped.
Prefer local compress over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools → Network, clear the log, try a non-sensitive sample. Pass = no multipart POST carrying your image to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If compress still works, upload-to-server architecture is off the table for that action.
Crop before you share. Hide the address bar and adjacent tabs in the copy you paste — not only in the archive you keep locally.

A local compress workflow

Pretty-Print JSON Without Leaking Tokens: A Local Checklist for API Debugging

Magill Anway — Sun, 20 Sep 2026 01:41:43 +0000

Pretty-Print JSON Without Leaking Tokens: A Local Checklist for API Debugging

Answer first: If the payload might contain access tokens, PII, or internal IDs, format it in your browser on your machine before you paste it into a ticket or a “free online JSON” site. Cloud formatters are convenient — and they are also a third party that briefly holds every key in the response. Below is a practical checklist plus a local workflow.

Why this keeps showing up

Support threads and Discord pastes still treat JSON beautifiers like notepads. The useful takeaway is not another brand name — it is a habit: treat the response as sensitive until you have redacted it, then share a trimmed copy once.

Pre-format checklist (2 minutes)

Know what is secret. Authorization, refresh tokens, emails, internal URLs. Assume the whole blob is hot until proven otherwise.
Prefer local format over “upload then hope the host deletes it.” Fewer hops means fewer accidental leaks into vendor logs.
Watch the Network tab. Open DevTools → Network, clear the log, paste a non-sensitive sample. Pass = no multipart POST carrying your JSON to a third-party API.
Airplane-mode sanity check. After page assets load, go offline and retry. If pretty-print still works, upload-to-server architecture is off the table for that action.
Redact before you share. Replace tokens with *** in the copy you put in Linear/Jira, not in the live response you keep locally.

A local format workflow

Step 3 — Redact

Search for Bearer, token, @, and internal hostnames. Strip or mask before paste.

Step 4 — Share once

Skip the detour through a random “free JSON online” host for payloads you would not email to a stranger.

One browser-local starting point

When you need an on-device formatter without creating an account, this JSON Formatter runs in the tab (files stay on your device):

https://www.lizecheng.net/dev/json-formatter/?utm_source=devto&utm_medium=article&utm_campaign=lizely_daily_20260920&utm_content=json-formatter

(That is the only product link in this post.)

What “good enough” looks like

Scenario	Local move
Debug a 401 with a huge body	Format locally → redact → paste snippet
Share sample webhook payload	Format → strip secrets → ticket
Compare two API versions	Format both locally; do not upload either
Tokens in nested objects	Search the tree before any cloud hop

Closing

JSON formatting is a solved UX problem. The open question is whether the bytes leave your device on the way. Prefer tools you can verify with Network + offline checks — and keep cloud beautifiers for files you would not mind a stranger reading.

Step 1 — Capture the response

Copy from DevTools or save the .json from your client. Keep the original offline.

Step 2 — Pretty-print in the tab

Format locally. Closing the tab should clear in-memory copies; the file you download (if any) is the artifact you keep.