DEV Community: 王磊

Why My iPhone File Picker Greyed Out Every PST File I Asked For

王磊 — Mon, 02 Nov 2026 02:06:50 +0000

WebKit maps accept extensions to MIME types, drops the ones it doesn't know, and then limits the Files app to whatever is left. For a mail archive tool, that is almost everything that matters.

I run a browser tool that opens Outlook .pst and .ost files without Outlook. For months the homepage said it worked on a Mac, a PC, a Chromebook, or an Android phone. Google was suggesting "open pst file on ipad" next to "on android" and "on chromebook". Bing showed tablet-flavoured queries. The site said nothing about an iPad or an iPhone.

That gap was not just marketing. On iOS the file picker itself can quietly refuse the files the page is built for. Here is what I measured, why the picker behaves that way, and what the page now does about it.

First, does the engine even open a PST?

Before writing any "works on iPad" claim, I ran the live site in Playwright's WebKit 26.6 with the iPad Pro 11 and iPhone 15 profiles. That is Apple's engine in an emulated viewport, not a physical iPad's memory or its Files UI, so the claim has to stay within what that run shows.

Results with the public Enron test PST (14 MB, read whole) and a 108 MB copy (read in pages):

11 folders and 71 messages opened in about 0.8 seconds
search returned hits
tapping a message opened it
no page errors, no sideways scroll

So the readers work in WebKit. PST, OST and MBOX are read in pages rather than held whole in memory, which is the same path Android and desktop use for large files. That is the engine half of the story. The picker is the other half.

What `<input accept=".pst,.ost,…">` does on iOS

On iPhone and iPad every browser is WebKit. When a page sets the file input's accept attribute to a list of extensions, WebKit does not pass those extensions through to the Files app as filenames. It looks each one up in the system's extension-to-MIME table and drops any extension that has no entry.

Of the archive types this tool accepts:

Extension	iOS has a MIME mapping?
`.eml`	yes (`message/rfc822`)
`.zip`	yes (`application/zip`)
`.pst`, `.ost`, `.olm`, `.mbox`, `.msg`	no

If anything survives that lookup, the Files picker opens limited to the survivors. A homepage that listed .pst,.ost,.eml,.mbox,… therefore opened a picker in which every archive type but .eml and .zip was greyed out — including the .pst the visitor came to open.

If nothing survives, the picker allows every file. So the failure mode is not "no accept breaks iOS". It is "a mixed list that includes one known type silently filters out every unknown type".

(The WebKit side of this lives in WKFileUploadPanel and the Cocoa MIME registry: extensions go through UTI / MIME lookup before the menu is shown. I am not claiming a new WebKit bug; I am describing the behaviour a page has to work around.)

This matched older analytics too: across ninety days there had been iOS visitors and zero successful opens. The engine was fine. The picker was the wall.

The rule the page uses now

The accept string is built by a small helper. On an Apple touch device it is kept only when every listed extension is one iOS can type. Otherwise it is left off, and the content check that already runs after a pick tells a wrong file apart.

export const IOS_TYPED_EXTENSIONS: ReadonlySet<string> = new Set([
  "eml",
  "zip",
]);

export function fileInputAccept(
  formats: readonly string[],
  appleTouch: boolean,
): string | undefined {
  if (formats.length === 0) return undefined;
  if (appleTouch && !formats.every((f) => IOS_TYPED_EXTENSIONS.has(f))) {
    return undefined;
  }
  return formats.map((f) => `.${f}`).join(",");
}

Detecting "Apple touch" needs one extra check: modern iPadOS often sends a Macintosh user agent, and gives itself away by having a touch screen (maxTouchPoints > 1). Matching only /iPhone|iPad|iPod/ misses those iPads.

A page that accepts only .eml and .zip still gets an accept attribute. A page that mixes in .pst or .mbox does not. Tests pin both the helper and the homepage copy to that set, so a future format list cannot drift from the FAQ.

What the homepage now says

The hero line names an iPad next to the platforms that were already there. A new FAQ answers "Can I open a PST file on an iPad or iPhone?" with the practical path:

Yes, in Safari.
Tap the drop area and choose the file in the Files app.
The picker lists every file, because naming archive types by extension would grey most of them out.
Whatever you choose is checked by its contents once picked.
Large PST / OST / MBOX files are still read in pages.

The same platform line went into llms.txt, so answer engines that quote the site don't keep saying "Mac, PC, Chromebook, Android" and stop there.

Limits I am not papering over

The WebKit run is an engine-and-layout check. It is not a measurement of a specific iPad's free RAM, nor of every Files location (iCloud Drive, On My iPhone, shared folders).
Leaving accept off means the picker shows photos, PDFs and everything else. That is deliberate. The content sniffer rejects non-archives after the pick; the cost is one extra tap for someone who picks the wrong file.
OLM, ZIP and MSG are still read whole into the tab. A phone runs out of memory for those sooner than a laptop. The iPad answer sticks to PST / OST / MBOX for the paging claim, which is what the code actually pages.

Takeaways

On iOS, accept is a MIME filter in disguise. Unknown extensions vanish; known ones become the only things you can tap.
A mixed list is worse than no list, if your product's main format is in the unknown set.
Omit accept when you cannot name a typeable set, and validate by content after the pick.
Detect iPadOS by touch points, not by the word "iPad" in the user agent alone.
Don't claim a platform in the hero until the picker path on that platform has been walked.

If you need to open a PST on a tablet without Outlook, the homepage walkthrough is on Mailward. Disclosure: I built it. The file stays on the device; Safari opens it locally.

Putting Remote Email Images in a PDF From the Browser: CORS, Tracking Pixels, and Honest Failure Boxes

王磊 — Fri, 30 Oct 2026 02:58:56 +0000

I added "save this email as a PDF" to a browser-based mail viewer. Everything runs locally: the message is parsed in a Web Worker and the PDF is built with pdf-lib. Text, headers and attachments were easy. Images were the hard part.

Pictures an email carries inside itself (cid: references and data: URIs) are simple: the bytes are already in the message. Pictures an email links to (<img src="https://…">) are another story. My first version skipped them on purpose. Then a newsletter printed with blank gaps where its pictures should be, and it read like a bug. So I changed my mind, with constraints. Here is what those constraints are and why.

Why not just `fetch()` every `<img>`?

Two reasons, one about privacy and one about the platform.

Privacy. Loading a remote image tells the sender's server that the mail was opened, and from where. That is how tracking pixels work. A tool that promises "your mail never leaves your device" must not turn into an open-tracker by accident. So the rules are strict:

No proxy. The browser requests the image straight from the host that serves it; the request never goes through my site.
credentials: "omit" and referrerPolicy: "no-referrer", so no cookies and no page address are sent.
Images that are clearly beacons are never requested: width or height of 2px or less, or display:none.
Requests to private-network IP literals and the local machine are refused outright. A mail should not be able to make the converter poke at 169.254.169.254 or localhost.

The platform. From a page, fetch() of a cross-origin image is only readable if the host sends Access-Control-Allow-Origin. An <img> tag can display such a picture, but code can't get its bytes to embed in a PDF without CORS permission.

CORS makes a dead host and a refusing host look the same

When a CORS check fails, the browser gives your code a generic network error. You can't tell "this server is down" from "this server doesn't allow other sites to read its images" from "the picture moved". All look like a TypeError.

How common is it? I tried a set of popular image hosts on 2026-10-26. Roughly two thirds sent the header (GitHub, Substack, Amazon, LinkedIn, HubSpot, Klaviyo, Constant Contact, Shopify, Gravatar and googleusercontent did). Others did not: google.com/gstatic, SendGrid's S3 bucket, Campaign Monitor and apple.com. That is a small hand-picked sample, not a survey, but it is enough to say: a meaningful share of real newsletter images can't be embedded from a browser, and you can't fix that client-side.

So the design question became: what do you show in the PDF when a picture can't be had?

A box that says why, not a blank

Instead of a gap, the PDF gets a grey box: "Picture not included", the alt text if there is any, and a reason. The reasons I can distinguish:

a network or CORS failure: "host does not let other websites download its pictures, or is offline" (deliberately both, since the browser can't separate them);
HTTP 404 or 410: "host no longer has this picture";
the reply is too large;
the reply isn't an image;
the format can't be put in a PDF;
a cid: the message doesn't contain.

Two refinements keep the output tidy:

Adjacent pictures that fail for the same reason share one box, so a newsletter with twelve blocked banner slices doesn't become twelve grey rectangles.
A failed picture with no size and no alt text is left out entirely. That is almost certainly an open beacon, and a box for it would be noise.

The fetch rules in code

The request options are the small part:

const res = await fetch(url, {
  mode: "cors",
  credentials: "omit",
  referrerPolicy: "no-referrer",
  signal: AbortSignal.timeout(10_000),
});

Around it sit the guardrails:

http: and protocol-relative URLs are upgraded to https:.
A 10-second timeout and a 10 MB cap. The cap is enforced while streaming the body, so an oversized response is abandoned rather than buffered first.
The reply must carry an image content type or start with image magic bytes. A server can answer with something that isn't a picture, so the check doesn't rely on one signal alone.
At most 100 pictures per message, six requests in flight at a time.
A host that fails at the network level isn't asked again within that worker, so one dead host doesn't cost a timeout per picture.
Pictures up to 512 KB are cached by address, since the same logo appears many times in a mailbox.

Order matters when you parallelise

Exporting a folder of newsletters means many messages, each waiting on its own pictures. Rendering them one after another makes the slowest host stall everything. The folder export renders four messages at once. The output order stays that of the folder, which is the part that's easy to break: results are collected by index, not by completion time.

Testing without trusting the network

Unit tests exercise the rules without real servers: the address rules (0.gravatar.com is allowed, 169.254.169.254 is refused), the request options, each failure kind and its wording, the streamed size cap, one request per address and none after a host has failed, and that adjacent same-reason failures merge. For the real-browser behaviour, an end-to-end script in Chrome against a production build checks one CORS-friendly host (a GitHub avatar is drawn) and one that refuses (google.com's logo becomes a box with its reason), and asserts both requests went out without a referrer.

What I'd tell you if you build something similar

Decide your privacy rule first, then see which features survive it. "No proxy" is what forces the grey boxes.
Don't pretend you know why a CORS failure happened. Say the two things it could be.
Filter beacons before requesting, not after.
Cap size while streaming, and verify the content, not just the header.
Keep output order independent of completion order when you parallelise.

If you want to see how it behaves on your own .eml files, the page is the EML to PDF converter. Disclosure: I built it. The message is processed in your browser; the only requests it makes are for fonts and emoji pictures from the site itself, and for the pictures the message itself links to, which go to their own servers.

Why My PST Reader Showed 24 of 160 Items in an Outlook OST (and Raised No Error)

王磊 — Thu, 29 Oct 2026 02:16:07 +0000

A debugging story about row matrices, an 8 KB assumption, and a loop that stopped without telling anyone.

Here is the kind of bug I like least: nothing crashes, nothing logs, and the output looks plausible. A folder simply has fewer items than it should.

I work on a browser-based viewer for Outlook mail files. It reads .pst and .ost files locally with a JavaScript library called pst-extractor and a good deal of my own code around it. While testing with an Outlook 2013+ OST (the offline cache Outlook keeps for an Exchange or Microsoft 365 mailbox), I opened a calendar folder named "United States holidays". The folder tree said 160 items. The list showed 24. No exception, no warning.

Here is what I found and how I fixed it. If you ever parse a PST or OST, one of these details may save you an afternoon.

Two layouts that share a name

Outlook's personal-folder files come in more than one layout. The old ANSI format, the Unicode PST, and the Outlook 2013+ files that use 4 KB pages (version number 36 in the header, which is what my test file reports) are all "PST-family" files, but they don't store data blocks the same way.

Folder contents in these files are stored in a Table Context, which is, roughly, a table with a "row matrix": fixed-size rows laid out one after another. Each row starts with a 4-byte row ID. A separate row index maps row IDs to row numbers.

To read row r, a parser needs the byte offset of that row. The library I use computes it the way the Unicode PST layout dictates: data blocks of 8,176 bytes, with padding at the end of each block, so

offset(r) = floor(r / rowsPerBlock) × 8176 + (r mod rowsPerBlock) × rowSize

That is correct for Unicode PSTs. It is wrong for a 4K OST.

What the 4K OST actually contains

In my test file, the contents table of the 160-item calendar folder is a single deflate-compressed block of 54,240 bytes. That is exactly 160 rows × 339 bytes per row, with no padding. The data blocks in this layout are larger than 8 KB.

Now apply the 8 KB arithmetic. Row 24 should start at byte 8,136 (24 × 339), but the formula treats a block as ending at 8,176 and reads row 24 from byte 8,176 instead. It finds whatever bytes are there and reads a garbage row ID.

The folder cursor (the code that pages through items) treats a row ID that doesn't make sense as the end of the table. It stops. No error. The library reported rowCount as 159, and the list showed 24.

That's the whole bug: one layout assumption, applied to a file format that breaks it, and a loop that fails quietly instead of loudly.

The fix: stop computing offsets, find them

I didn't want to rewrite the whole reader. The fix patches the table class for the 4K layout only, and leaves Unicode and ANSI files on the library's original code path.

The idea: don't compute where row r is, locate it, and verify.

Row 0 starts at offset 0.
Row r starts where row r-1 ended.
Check it: read the 4-byte row ID at that offset, look it up in the table's row index, and confirm that it maps to row number r.
If it doesn't match, look further, within the next rowSize - 1 bytes. This covers the case where a row matrix spans several blocks and the writer left padding at the end of a block (the libpff documentation describes that padding).
If the row still can't be found, end the table rather than return a garbage row.

In code:

export function locateRows(
  readRowId: (offset: number) => number,
  length: number,
  rowSize: number,
  rowIndexById: ReadonlyMap<number, number>,
): number[] {
  const offsets: number[] = [];
  if (rowSize <= 0) return offsets;
  let at = 0;
  for (let row = 0; row < rowIndexById.size; row++) {
    let found = -1;
    for (let p = at; p < at + rowSize && p + rowSize <= length; p++) {
      if (rowIndexById.get(readRowId(p)) === row) { found = p; break; }
    }
    if (found < 0) break;
    offsets.push(found);
    at = found + rowSize;
  }
  return offsets;
}

The check against the row index is the important part. It turns "I assume this offset is right" into "this offset is right, because the row at it says it is row r." A wrong guess ends the table instead of producing wrong data.

Reusing the library's own row parsing

Locating rows is half of it. Decoding a row is still the library's job, and I wanted to keep it. The library reads row r at r × rowSize from the start of a node. So for each row, I hand it a node shifted by the difference between where the row really is and where the library will look:

const shift = offsets[row] - row * t.TCI_bm;
t.rowNodeInfo = new NodeInfo(node.startOffset + shift, node.endOffset + shift, node.pstNodeInputStream);
rows.push(originalGetItems.call(this, row, 1)[0]);

For the duration of the call the library's block size is set to a huge value, so its own padding step never kicks in, and the original node is restored in a finally. The rowCount getter is overridden the same way for 4K files. It is a monkey patch, but a contained one: it only applies when the file's type is the 4K one.

The "end of table" signal

The library's folder cursor stops when it reads a row carrying a particular sentinel. When my locator has no more rows, the patched getItems returns exactly that sentinel (a fake row with item index −1), so the cursor ends cleanly instead of reading past what was located.

Testing, and what I could not test

The regression test uses the library's own test OST (MIT-licensed test data, gzipped in my fixtures). It asserts:

the header is the 4K layout (!BDN magic, version 36);
the "United States holidays" folder lists all 160 items, and row 24, the first one the 8 KB arithmetic misplaced, matches the full listing;
paging works at the end of the table (asking for 50 items from row 150 returns 10);
every message folder in that file lists the count the folder tree shows, and the result is the same through a paged reader with a small cache;
a regular Unicode PST still lists the same 71 messages as before, so the patch doesn't touch it.

One limit I want to be upfront about: I did not have a real 4K OST whose row matrix spans multiple blocks. The "look past the block's tail padding" path is covered only by tests on synthetic data, where I build matrices with padding between blocks and check that the offsets come out right. The real-file case I verified is the single-block one. If you have a multi-block 4K sample, that's the case I'd most like to see.

Takeaways

A "file format" often means several layouts. Check which one your library's arithmetic was written for.
Silent truncation is worse than a crash. If a loop ends early, cross-check it against a count you already have (here, the folder's 160 versus the 24 listed).
Prefer locate and verify over compute and trust when a format has self-describing indexes.
Keep a patch narrowly scoped (one layout), and leave the working path alone.

If you want to try it on your own file, the tool's OST viewer page is where this lives. Disclosure: I built it. It reads the file in your browser without uploading it.

Splitting an Audio Project at Label Marks, the Way Audacity Does It (and Batch-Exporting Many Projects)

王磊 — Wed, 28 Oct 2026 03:30:54 +0000

If you edit podcasts or long recordings in Audacity, you probably use label tracks: little text marks on the timeline ("Intro", "Interview", "Outro"). Audacity can split a project into one file per label (Export Multiple → Split files based on Labels). I recently added the same thing to a browser-based .aup3/.aup4 tool, plus a batch mode for several projects at once. Reproducing the rule exactly took more care than I expected, so here is how it works and what tripped me up.

Where labels live

A label track is stored in the project document as <labeltrack> containing <label t="…" t1="…" title="…"/> elements. t is the start in seconds and t1 the end. I checked the writer (LabelTrack::WriteXML) in Audacity 3.7.9 and 4.0.0 and the same names show up in .aup3, .aup4 and the old XML-based 1.x/2.x .aup, so one reader covers all three. Audacity 4.0 only adds an isSelected attribute.

Two label kinds share this structure:

a region label has t1 > t;
a point label has t1 == t (or a missing or backwards t1, which I treat as a point).

That distinction drives the whole split rule.

The split rule

I followed what Audacity's export dialog code does (ExportAudioDialog::UpdateLabelExportSettings, read at the 4.0.0 tag):

Every label starts a file.
A region label ends its file at the region's own end.
A point label ends its file at the next label's start.
The last point label runs to the end of the audio.
Audio before the first label becomes a file only if you ask for it ("Include audio before first label", off by default), and it is named after the project.
An empty title becomes untitled.
Files are numbered 01-Title, 02-Title, … so they sort.

The core is small:

const sorted = [...labels].sort((a, b) => a.start - b.start || a.end - b.end);

sorted.forEach((label, index) => {
  const isPoint = label.end <= label.start;
  const end = !isPoint
    ? label.end
    : index < sorted.length - 1
      ? sorted[index + 1].start
      : duration;
  raw.push({
    number: index + 1,
    title: label.title.trim() || "untitled",
    start: label.start,
    end,
  });
});

Notice that a region label's end is not clipped to the next label. Overlapping regions produce overlapping files, which is what Audacity's rule does too.

Pitfalls

Segments need clamping. Label times come from a document a user may have edited, shortened, or hand-crafted. I clamp both ends into [0, duration] and drop any segment shorter than one sample (1/48000 s). Otherwise you export empty files.

File names are a mess. Titles contain /, :, ?, quotes and control characters, and two labels can have the same title. I replace the characters file systems reject with _ (similar to what Audacity's Internat::SanitiseFilename does), collapse whitespace, cap at 120 characters, and de-duplicate case-insensitively, since macOS and Windows treat Intro and intro as the same file:

let fileName = base;
for (let n = 2; used.has(fileName.toLowerCase()); n++) {
  fileName = `${base} (${n})`;
}
used.add(fileName.toLowerCase());

Audacity only looks at the first label track. A project can have several. Audacity's split always uses the first. I let the user pick which one, since a project with one label track for chapters and another for edit notes is common.

Each piece must be exactly its span of the mix. I render each file as a window of the whole mixed-down audio, rather than re-mixing each piece separately. A test checks that a split file is exactly its span of the mix.

Giving the pieces names players can read

Split MP3s carry a title and track number, written as an ID3v2.3 tag in front of the encoded stream. I chose v2.3 over v2.4 for its wider player support. The consequence is that v2.3 has no UTF-8, so text frames are UTF-16 with a byte-order mark. Frame sizes are plain big-endian in 2.3, and only the tag header's size is "syncsafe" (7 bits per byte) — an easy detail to get backwards.

Batch: many projects, one worker

If you drop two or more .aup3/.aup4 files (each with its own -wal if it has one) or a folder of them, the page lists them instead of opening one. The design decisions:

One project in memory at a time. The batch opens and exports projects sequentially in the same Web Worker. Opening them in parallel would multiply memory use, and projects can be large.
One failure never stops the batch. A project whose document doesn't decode is skipped and named in the report rather than aborting the run.
Everything goes into one ZIP, built in the browser, with a batch report.txt. Per project it lists the files produced, any unreadable blocks, effects that weren't rendered, and what was skipped or failed and why.
Optionally split each project at its labels, with a folder per project and each project's label file.

Deciding what a drop is lives in a pure planning function that looks at the dropped file names and returns a kind (single project, batch, and so on), so it can be unit-tested without a browser. Recovery and downgrade pages keep one project at a time.

What is free and what isn't

For transparency: reading labels and exporting Audacity's own label text file (start, end, title, tab-separated, six decimals — the format File → Import → Labels reads back) or "m:ss Title" timestamps is free. Splitting at labels, the chaptered MP3 and batch export are paid features in the tool.

Testing

The unit tests pin the document reading, the split rule, both text formats, the ID3 bytes and the free/paid split. The fixtures are two existing test projects with label tracks added; the audio is untouched. An end-to-end script runs the feature with real pointer events on desktop and phone viewports. Its first run caught label names overlapping in the phone-width timeline lane, so a point label's text now gets only the room up to the next label.

Try it

If you want to see this without installing Audacity, the splitting feature is described at Waveward's split-by-labels page. Disclosure: I built it. Everything runs in your browser, and projects are not uploaded.

Takeaways

Copy the reference implementation's rule, including its odd corners, and note which version you read.
Treat region and point labels differently; the next label's start is the only end a point label has.
Clamp, drop empty segments, sanitize and de-duplicate names.
Batch work: sequential, isolated failures, and a report that says what was skipped.

How to Open Outlook PST and OST Files Without Outlook

王磊 — Tue, 27 Oct 2026 03:37:52 +0000

Sooner or later someone hands you a .pst file. Maybe it's an old mailbox export from a former employee, an archive from a laptop you retired years ago, or evidence you need to review. You don't have Outlook installed, you're on Linux or macOS, or you simply don't want to set up a mail profile just to read a few messages.

This post covers what these files actually are and the practical ways to read them without Outlook, along with the privacy trade-offs of each approach.

What PST and OST files are

PST (Personal Storage Table) is Microsoft's file format for storing mail, contacts, calendar items and tasks locally. Outlook uses it for archives and for POP3 accounts, and it's what you get when you use File → Import/Export → Export to a file.

OST (Offline Storage Table) is a local cache of a server mailbox (Exchange, Microsoft 365, and IMAP accounts in newer Outlook versions). It lets Outlook work offline and syncs back to the server.

A few useful facts:

Both formats share the same underlying structure, documented by Microsoft as [MS-PST]. Internally it's a set of B-trees (a node B-tree and a block B-tree) with a "messaging layer" on top that represents folders, messages, and attachments as property sets.
There are two main variants: the old ANSI format (Outlook 97–2002, 2 GB limit) and the Unicode format (Outlook 2003 and later), which supports much larger files. Multi-gigabyte PSTs are common.
PSTs can be password-protected, but the "password" is a weak check stored in the file, and the content is usually only obfuscated with a simple encoding, not strongly encrypted. Don't treat it as a security boundary.
An OST is tied to the profile it was created for. Outlook itself won't open someone else's OST as a data file, but third-party parsers can often read it because the on-disk structure is the same.

Because the format is documented, there are good open-source parsers. You have real options.

Option 1: Use Outlook anyway (if you have access)

If you have a Windows machine with Outlook, it's still the most faithful viewer:

File → Open & Export → Open Outlook Data File to mount a PST alongside your mailbox, or
File → Open & Export → Import/Export → Import from another program or file to merge it.

This doesn't work for OST files from another profile. And it requires a licensed Outlook install, which is exactly what many people lack.

Option 2: libpff / pffexport (Linux, macOS)

libpff by Joachim Metz is a forensic-grade library for PST, OST, and PAB files. It ships with command-line tools:

pffinfo shows file metadata (format type, encryption type).
pffexport extracts the contents into a directory tree.

On Debian/Ubuntu:

sudo apt install pff-tools
pffinfo mailbox.pst
pffexport -m all -t out mailbox.pst

You get folders containing one directory per message, with headers, the body (plain text, HTML, or RTF), and attachments as separate files. It's great for forensic work or for grepping through mail, but it's not a mail client. libpff also handles OST files and can recover deleted items in some cases (-m all includes recovered and orphaned items).

Option 3: readpst → MBOX → Thunderbird

readpst comes from the libpst project. Its main advantage is that it converts to standard formats that ordinary mail clients understand.

# Debian/Ubuntu
sudo apt install pst-utils
# macOS
brew install libpst

mkdir out
readpst -r -o out mailbox.pst      # one MBOX per folder, preserving hierarchy
readpst -e -o out mailbox.pst      # one .eml file per message instead

Then, to read the result comfortably:

Install Thunderbird and the ImportExportTools NG add-on.
Create a Local Folder, right-click → ImportExportTools NG → Import mbox file.
Choose the MBOX files readpst produced (the "with sub-folders" option keeps the structure).

Now you have full search, threading, and attachment handling, all offline. This is my default recommendation for anyone comfortable with a terminal: everything stays on your machine, the tools are free and open source, and MBOX/EML are open formats you can keep long-term.

Caveats: very large or damaged files sometimes trip up readpst. If that happens, try pffexport, which is often more tolerant. Calendar and contact items are exported too, but they're less pleasant to browse than mail.

Option 4: Browser-based viewers

There's a class of tools that let you open a PST in a web page. They differ a lot in where the parsing happens, and that's the part you should check.

Upload-based converters send your file to a server, process it there, and give you back a download. They're convenient, but think about what's in a typical mailbox: contracts, password-reset emails, HR conversations, customers' personal data. Uploading that to an unknown third party may violate your company's policy or data-protection obligations (GDPR, client confidentiality, legal hold). Also, multi-GB uploads are slow and often fail.

Client-side viewers parse the file in the browser using JavaScript or WebAssembly. The file never leaves your machine. You can verify this yourself: open DevTools → Network, load a file, and watch for requests carrying its contents. Or disconnect from the network after the page loads and check that it still works.

One option in this category is Mailward (https://pst.aivismonitor.com/). Disclosure: I built Mailward. It parses PST/OST files locally in a Web Worker with no upload, handles multi-GB files, and shows the folder tree, message bodies, and attachments, with full-text search. Reading and searching are free (with 3 exports per day), and a $19 one-time Pro license adds batch MBOX/EML export. If you're happy in a terminal, readpst + Thunderbird above does a similar job for free.

Whatever browser tool you pick, run the DevTools check before you drop in a sensitive mailbox.

Step-by-step: which path should you take?

Identify the file. Run pffinfo file.pst (or check the extension and size). Note whether it's PST or OST, ANSI or Unicode.
Make a copy. Always work on a copy, especially with evidence or with a file that might be damaged. Some tools open files read-write.
Decide where the data is allowed to go. If the mailbox contains anything sensitive, rule out upload-based services. Stick to local tools (libpff, readpst, a client-side viewer) or Outlook.
Pick a tool for the job:
- Need to look up a few emails quickly: a local browser viewer or pffexport + grep.
- Need a long-term, searchable archive: readpst → MBOX → Thunderbird.
- Need forensic completeness or deleted items: pffexport -m all.
- Have Outlook and a PST from your own profile: just open it in Outlook.
Verify the result. Compare folder counts and spot-check a few messages with attachments and non-ASCII text (encoding issues show up there first).
Clean up. Exported folders contain plaintext copies of everything. Delete them securely when you're done, or store them with the same care as the original.

Wrapping up

PST and OST look like proprietary black boxes, but the format is documented and well supported by open-source tools. On Linux and macOS, readpst and pffexport cover most needs. Thunderbird gives you a comfortable reading experience, and client-side browser viewers are a zero-install option. Whatever you choose, think about where your data goes before you think about convenience.

Parsing multi-gigabyte Outlook PST files in the browser

王磊 — Fri, 14 Aug 2026 01:30:36 +0000

Disclosure up front: I build Mailward, a browser-based PST/OST/OLM/MBOX/EML viewer. These are the implementation notes.

A PST file is not a folder of emails. It is a single-file B-tree database — Microsoft documents the layout as [MS-PST] — and the mail inside exists only as sets of typed properties. To show one message you walk the B-trees, resolve the property set, and reconstruct an RFC 5322 message from scratch.

Now do that in a browser tab, for a 4 GB file, without uploading it anywhere and without loading it into memory.

The constraint that shapes everything

The whole point of a browser-side viewer is privacy: the file never leaves the machine. That rules out "stream it to a server". And FileReader.readAsArrayBuffer on the whole file rules itself out the moment archives pass a gigabyte — mobile Safari will simply kill the tab.

So the parser must do random access over a File it never fully reads.

One method to intercept

We build on pst-extractor, a faithful JS port of java-libpst. It has one architectural gift: every byte it reads funnels through a single method, PSTFile.readSync(buffer, length, position).

That means you can subclass PSTFile and reroute all I/O without touching parser internals:

import { PSTFile } from "pst-extractor";

let pendingReader: RandomAccessReader | null = null;

class ReaderBackedPSTFile extends PSTFile {
  archiveReader!: RandomAccessReader;

  constructor(reader: RandomAccessReader) {
    pendingReader = reader; // super() reads the 514-byte header via readSync
    try {
      super(Buffer.alloc(0));
    } finally {
      pendingReader = null;
    }
    this.archiveReader = reader;
  }
}

(ReaderBackedPSTFile.prototype as any).readSync = function (
  buffer: Buffer, length: number, position: number
): number {
  return (this.archiveReader ?? pendingReader).read(buffer, length, position);
};

Two quirks worth explaining:

The override lives on the prototype, outside the class body, because PSTFile's constructor immediately reads the 514-byte header — so the replacement must already be installed while super() runs.
Instance fields don't exist yet at that point, hence the module-scoped pendingReader handoff. Workers are single-threaded, so this is safe.

The reader: 64 KB pages, LRU-capped

RandomAccessReader is a paged view of the file:

64 KB pages, loaded on demand.
LRU cache capped at 1024 pages — 64 MB worst case, regardless of file size.
Reads that span page boundaries are assembled from multiple pages.

Inside a Web Worker the page loader is almost embarrassingly small, because FileReaderSync gives you synchronous random access to a user-selected File:

class FileSlicePageLoader {
  private reader = new FileReaderSync();
  constructor(private file: Blob) {}

  loadPage(start: number, length: number): Uint8Array {
    return new Uint8Array(
      this.reader.readAsArrayBuffer(this.file.slice(start, start + length))
    );
  }
}

file.slice() doesn't copy — it's a view. We measured a 4 KB slice read at ~200 µs in Chrome, which makes B-tree walks feel instant. The same RandomAccessReader interface is backed by a plain Buffer in Node, so the entire parser is testable outside the browser.

If you're in Node, you don't need any of this

pst-extractor's constructor accepts either a Buffer or a filename. The 2 GB failures people report almost always come from fs.readFileSync → Buffer. Pass the path instead and the library reads through a file descriptor with no Buffer ceiling:

const pst = new PSTFile("/path/to/large.pst"); // descriptor-backed

What this doesn't solve

Honesty section: none of this repairs a corrupted PST — if scanpst can't open it, a reader can't either. And ANSI-era PSTs (Outlook 97–2002, the 2 GB-capped variant) parse through the same pipeline in theory, but genuine ANSI files written by 20-year-old Outlook are nearly impossible to test against, so we claim "likely works, fails loudly" rather than "supported".

More format field notes (OST's account lock, OLM's timezone-less UTC timestamps, MBOX From-munging) live in this repo: email-archive-formats.

Shopify Markets CSV Price Updates: A Safer Way to Verify Catalog Imports

王磊 — Wed, 05 Aug 2026 01:40:32 +0000

A Shopify CSV import can finish without an obvious error and still leave a market catalog with the wrong price or fewer variants than the base catalog.

This is especially easy to miss after the change from Markets to Catalogs. A product import CSV and a catalog-specific price CSV may look similar, but they are not interchangeable workflows. The safest approach is to treat a market-price update as a small data-reconciliation job.

Why a successful import is not proof

There are three separate questions:

Did Shopify parse the CSV?
Did the intended Handle/SKU rows match the right variants?
Did the target catalog apply the expected price and inclusion state?

The first answer can be "yes" while the second or third is "no." A catalog can fall back to a base price, omit a variant, or keep an old inclusion value without producing the kind of row-level error merchants expect.

A safer workflow

1. Save a baseline

Export the current product state and record the target market/catalog, export date, currency, and number of products and variants. Keep this as a rollback reference. Do not start by editing the only copy of the export.

2. Use the target catalog's own template

Open the specific catalog you intend to update and download its sample or export format when Shopify provides one. Do not assume that columns such as Price / US, Price / UK, or Included / US belong in the ordinary product import flow.

For a catalog-specific file, keep the smallest set of columns that the template documents. In many workflows that means an identity pair plus the catalog fields, for example:

Example columns: Handle, SKU, Price, Included.

Example row: blue-shirt, BLUE-S, 29.90, true.

Use your actual exported headers and identifiers; the example is only a shape, not a universal Shopify template.

3. Normalize numbers before checking catalog behavior

Prices should be numeric and consistent:

Use a decimal point, not a locale comma, unless the target template explicitly says otherwise.
Remove currency symbols and thousands separators.
Keep one currency per file and confirm the catalog currency before importing.
Check for formulas that exported as blank strings or text.
Make sure the same SKU is not repeated for two different variant rows unless that is intentional.

A browser-side numeric price-format check can catch malformed price cells before they create noise in the catalog test. It cannot prove that Shopify mapped a row to the correct market catalog, so treat it as the formatting step only.

4. Compare identities and counts

Before importing, compare the Handles and SKUs in the proposed file with the baseline export. Record:

total rows in the proposed file;
unique Handle + SKU pairs;
missing identifiers;
duplicate identity pairs;
products with fewer or more variant rows than expected.

This catches a common false positive: the file is valid, but the catalog receives only part of the intended variant set.

5. Test a small, multi-variant sample

Choose a few products that cover the risky cases: one single-variant product, one product with several options, one sale-price change, and one product that should be excluded from the target catalog.

After the import, check the catalog itself. Do not rely only on the import toast or the product page's base price.

6. Verify the result in the target catalog

For each sample, confirm the market price, currency display, included/excluded state, and variant count. Then compare the post-import export with the baseline. If one market shows fewer variants or the base price appears in place of the market price, stop the full rollout and isolate that catalog's template and identity rules.

7. Keep a rollback path

Store the original export, the exact file you imported, a short change summary, and the post-import verification result. For a large catalog, keep an exception sheet rather than repeatedly re-importing the whole file while guessing.

The practical boundary

A general CSV validator can help with headers, encoding, row identity, file size, and numeric price formatting. It cannot read Shopify's private catalog state or guarantee that an import changed every market correctly.

That boundary matters: "CSV accepted" is an input check; "catalog prices and variant coverage match the plan" is a post-import reconciliation check. Keeping those two claims separate makes international price updates much safer.

Bulk Update Shopify Product Descriptions and Images Without Blank Overwrites

王磊 — Mon, 03 Aug 2026 01:39:47 +0000

Bulk catalog edits are easy to start and surprisingly easy to make dangerous.

If you need to update hundreds of Shopify product descriptions and replace images, the safest workflow is usually a small, intentional CSV update—not a full export with every column left in place.

1. Start with a fresh Shopify export

Export the products immediately before preparing the change. Keep that original file untouched as your rollback reference. Do not build a new file from memory: the export contains the exact Handles, option rows, and variant structure Shopify currently knows.

For a description-only change, identify the columns you actually need:

Handle
Title
Body (HTML)

If you are changing prices, SKUs, inventory, or variant options at the same time, treat that as a separate change set. Mixing unrelated edits makes it much harder to explain a partial import or recover from an overwrite.

2. Generate the repeated description in a spreadsheet

A spreadsheet formula is enough when the template is stable. For example, if the product title is in column B, a Google Sheets formula can build a simple HTML description:

="<p><strong>"&B2&"</strong> is handcrafted and ships free in 2 days. 30-day returns on every "&B2&".</p>"

Adjust the wording for your store, fill the formula down, then copy the result and paste it back as values into Body (HTML). Values-only paste prevents a later formula change from silently changing the import file.

Keep the original Title column while you work. It is useful for reviewing the generated text, even though the description is the field you intend to update.

3. Avoid the blank-column trap

For an existing-product update, an omitted column and an included blank column do not mean the same thing. A blank column can clear existing data, while an omitted column leaves that field alone.

Before importing, remove every column you are not deliberately updating. Preserve all variant rows for each Handle if your file still contains variant-level fields. Never sort rows in a way that breaks the product's Handle grouping, and never remove option columns from a variant update without first checking how Shopify will match the variants.

4. Treat images as a separate decision

A Shopify product CSV carries image references, not files sitting on your laptop. If new images are already hosted, use direct public https:// URLs in Image Src and keep the Handle and image position mapping consistent. If the files are local, upload them to a location that produces stable public URLs before importing.

Do not mix a large image replacement with a description update unless you have a clear reason. A description-only pilot is easier to verify, and an image-only pilot makes URL or row-mapping failures much easier to isolate.

5. Pilot before the full catalog

Import one or two representative products first. Confirm the description, variant count, image order, and unchanged fields in Shopify admin. Keep the pre-import export and the exact CSV you uploaded.

After the pilot, export the affected products again and compare the before/after values. Only then expand to the rest of the catalog. If the catalog is large, split the work into batches that each have a clear product range and a simple rollback point.

For a faster preflight of identity matching, changed columns, blank overwrites, and update-only risk, I use this browser-side Shopify existing-product CSV update audit. It does not import into Shopify or replace the pilot; it helps make the file's intended change set visible before you upload it.

A Safer Way to Bulk-Update Shopify Product Descriptions by CSV

王磊 — Sat, 01 Aug 2026 01:39:09 +0000

Bulk-editing 200 Shopify product descriptions sounds like a spreadsheet task. It is, but the dangerous part is usually not the formula. It is sending a full export back to Shopify with columns you did not intend to change.

A safer workflow separates content generation, import scope, and post-import verification.

1. Start with a dated baseline

Export the products before making edits and keep that file unchanged. Treat it as the rollback reference, not as the file you will immediately import.

Record which products are in scope and keep the export date in the filename. If an app or another team member changes the catalog while you work, the baseline can become stale, so re-export before a large production update when possible.

2. Generate descriptions in a separate column

In Excel or Google Sheets, build the new Body (HTML) value from the existing Title column and your approved template. Review a few short, long, and unusual titles manually before filling the formula down.

Keep the original description in a separate working column until the new text has been reviewed. Do not paste spreadsheet formulas into Shopify; paste values into Body (HTML) after the formula is checked.

This is also the point to decide whether HTML is really needed. Unescaped quotes, copied rich text, and spreadsheet formatting can create a description that looks acceptable in the sheet but behaves differently after import.

3. Trim the import file

For a description-only update, the file should normally contain only the stable identifier and the fields you intentionally changed:

Handle
Title, if you are using it for review
Body (HTML)

An included blank cell can clear an existing value. A column that is absent is different: Shopify cannot update what you did not include. Remove unused price, inventory, option, image, and metafield columns instead of leaving them blank.

If you are changing variants, keep the relevant option and identity columns together and test one multi-variant product first. A description update should not accidentally become a variant update.

4. Treat images as a separate job

A product CSV carries image URLs; it does not upload image files from your computer. For new images, prepare stable public URLs first, then review Image Src, Image Position, and the repeated Handle rows together.

Check that each URL is reachable and that the image order is intentional. Do not assume a reachable URL proves that Shopify will associate every Variant Image reference correctly. If the images are only local files, upload them through an appropriate Shopify workflow before preparing the CSV.

5. Run a preflight before production

Use a small representative batch first, then compare the exported result with the baseline. Look specifically for changed Handles, missing variant rows, unexpected blank cells, and fields that changed outside the requested description scope.

A browser-side checker such as the Shopify CSV Existing Product Update Audit can flag missing identifiers and risky blank cells, then produce a smaller update file for manual review: https://shopify-csv.aivismonitor.com/shopify-csv-existing-product-update-audit

The checker does not write to Shopify or guarantee a rollback. That boundary is useful: the merchant still decides which rows to import and verifies the result.

6. Verify after import

Open a few updated products and confirm the rendered description, HTML structure, image count, image order, options, and variant identities. Compare a fresh export with the pre-import baseline. If anything outside the intended fields changed, stop the next batch and investigate before continuing.

The repeatable rule is simple: generate in a working sheet, import the smallest intentional file, and verify the exported result before scaling up.

Shopify CSV Cost per Item: Audit It Before You Create a Purchase Order

王磊 — Thu, 30 Jul 2026 01:41:57 +0000

A native Shopify Purchase Order can leave line-item costs blank even when a variant already has a Cost per item value. That is a workflow gap, not necessarily a bad CSV.

A CSV can still help you prepare the numbers safely, but it cannot reach into a native Purchase Order and fill its lines. Treat the CSV step as a controlled cost review before you create or receive the PO.

1. Start with a fresh product export

Keep the original export unchanged. Work from a copy that includes the fields you need to identify each variant and compare the economics:

Handle
Title
Variant SKU
Variant Price
Cost per item

If your catalog uses barcodes or another stable identity, keep that reference too. Do not delete the baseline: it is the evidence you need if a later import changes more rows than intended.

2. Check identity before checking the numbers

A cost value is only useful when it is attached to the right variant. Before reviewing costs:

Look for blank or repeated identifiers.
Confirm that the SKU or other identity maps to one intended variant.
Keep option values when several variants share a product Handle.
Separate a supplier SKU from Shopify's own Variant SKU instead of silently treating them as interchangeable.

This prevents a clean-looking cost column from being applied to the wrong size, color, or pack.

3. Review Cost per item beside Variant Price

For each variant, check:

Cost per item is present and numeric.
Variant Price is present and numeric.
Cost is lower than price when a sale is expected to be profitable.
A blank, zero, or unusually large value is reviewed instead of being accepted automatically.
A supplier cost increase does not quietly turn a previously healthy margin into a loss.

The Shopify product CSV margin audit can calculate the margin amount and percentage locally from those columns and surface missing cost, invalid price, and low-margin rows for review.

4. Separate standing cost from the PO cost

Cost per item is a product-level reference. A Purchase Order is a specific supplier agreement at a specific time. If two suppliers quote different prices, keep the agreed PO cost in your purchasing worksheet and decide deliberately whether the standing product cost should change.

A practical worksheet can include:

Supplier and supplier SKU
Shopify Variant SKU
Ordered quantity and location
Agreed unit cost and currency
Freight, duty, or other adjustments
The date and reason for any standing-cost change

This preserves the historical price you actually agreed to instead of rewriting it later when a supplier sends a new list.

5. Test the smallest safe change

If you need to update product costs through Shopify's CSV workflow, use one representative product or a very small variant batch first. Compare the result with the original export, then expand only after the identifiers and cost values are confirmed.

Do not assume that a successful product CSV import means the native Purchase Order was populated. Verify the PO lines separately in Shopify and record any manual cost entry that remains.

What this workflow does not do

A browser-side CSV review cannot access a merchant's admin, read native Purchase Orders, call the Admin API, or write costs back automatically. It prepares evidence and a safer review path; the final Shopify import and PO entry remain manual actions.

That boundary is useful: it keeps supplier and store data local, makes the cost decision explicit, and avoids presenting a worksheet as an integration that Shopify does not expose.

Shopify CSV Files Over 15MB: Split by Product Handle, Not Row Count

王磊 — Tue, 28 Jul 2026 01:40:08 +0000

When a Shopify product CSV grows past 15 MB, making it smaller is only half the job. The split must keep each product together, or Shopify may receive variants and image rows without the parent context they need.

A safer batching checklist

Keep the untouched Shopify export as your rollback reference. Make a working copy before removing or reordering anything.
Group rows by the exact Handle. Do not split after an arbitrary line number: one product can occupy several rows.
Keep every variant row for a Handle in the same batch. Check Option values, Variant SKU, price, inventory, and barcode together.
Keep the product's image rows with the same Handle. Moving an Image Src row into another file can attach media to the wrong product or make the import harder to audit.
Check each batch independently for headers, UTF-8 text, prices, and duplicate Handles before importing.
Import a small representative batch first. Confirm product count, variant count, prices, inventory, and images before continuing with the remaining files.
Keep a simple batch log: file name, Handle range, row count, import time, and any Shopify warning. This makes a partial retry much safer.

The 15 MB limit is a file-size boundary, not a promise that a large catalog will import cleanly. Long descriptions and image URLs can push a file over the limit, while a row-count split can quietly break variant groups. A handle-aware split plus a post-import spot check gives you a better audit trail.

For a browser-side check and handle-aware batching guide, see the Shopify CSV size checker. It prepares review guidance locally; it does not upload files to Shopify or change products in your admin.

Shopify CSV Prices That Look Right but Still Fail: A Pre-Import Checklist

王磊 — Sat, 25 Jul 2026 01:43:09 +0000

A Shopify CSV can look perfectly normal in a spreadsheet and still fail, skip values, or change the wrong variants after import. Price columns are a common reason: spreadsheet locale settings, currency symbols, thousands separators, and variant-row matching can all change what Shopify receives.

Here is a practical pre-import checklist.

1. Start from a Shopify export

Use a recent product export as your baseline. Keep the original file untouched, then make a working copy for edits. Confirm that the file uses Shopify's expected headers, especially Handle, Option1 Value, Variant SKU, Variant Price, and, when relevant, Variant Compare At Price.

Do not rebuild a large catalog from a blank spreadsheet unless you have a strong reason. The export preserves the row structure that Shopify uses to group products and variants.

2. Make the price format unambiguous

Before saving the CSV, check that:

prices use a decimal point, not a locale-specific decimal comma;
currency symbols are not embedded in the cell value;
thousands separators are not left in values such as 1,299.00 unless your cleaning step removes them safely;
empty cells are intentional, especially on continuation rows;
compare-at prices are reviewed together with the selling price.

If the spreadsheet displays a value as currency, inspect the raw cell value before exporting. A display format can hide characters that end up in the CSV.

3. Verify variant identity before changing prices

A correct price on the wrong variant is still a bad import. For each product, check that:

every variant row keeps the same Handle;
option names and values stay paired;
SKU or another stable identifier matches the baseline export;
the update file does not accidentally include blank columns that could overwrite existing data;
the number of variant rows is unchanged unless you intentionally add or remove variants.

For a large catalog, test one representative product with multiple options before preparing the full file.

4. Scan the working copy

Run the working CSV through a local checker and review critical findings before exporting a cleaned copy. Pay special attention to malformed prices, unexpected headers, encoding warnings, duplicate handles, and file-size warnings. Treat the report as a preflight review; it cannot know whether a particular sale price is commercially correct.

For a quick browser-side check, use the Shopify CSV price format fixer to review price cells and export a cleaned copy when the correction is unambiguous.

5. Import a tiny batch and compare

Import a small set of products first. After Shopify finishes, compare the result against the baseline:

selling price and compare-at price;
variant SKU and option values;
inventory policy and availability;
product count and handle count.

If the result differs from the plan, stop before uploading the full catalog. Keep the original export and the tested CSV so you can explain exactly what changed.

Final caution

A CSV preflight does not replace Shopify's importer, change market-specific pricing, or guarantee that a theme or app will display prices as expected. It helps narrow down file-level risks so the next import is easier to verify.

DEV Community: 王磊

Why My iPhone File Picker Greyed Out Every PST File I Asked For

First, does the engine even open a PST?

What <input accept=".pst,.ost,…"> does on iOS

The rule the page uses now

What the homepage now says

Limits I am not papering over

Takeaways

Putting Remote Email Images in a PDF From the Browser: CORS, Tracking Pixels, and Honest Failure Boxes

Why not just fetch() every <img>?

CORS makes a dead host and a refusing host look the same

A box that says why, not a blank

The fetch rules in code

Order matters when you parallelise

Testing without trusting the network

What I'd tell you if you build something similar

Why My PST Reader Showed 24 of 160 Items in an Outlook OST (and Raised No Error)

Two layouts that share a name

What the 4K OST actually contains

The fix: stop computing offsets, find them

Reusing the library's own row parsing

The "end of table" signal

Testing, and what I could not test

Takeaways

Splitting an Audio Project at Label Marks, the Way Audacity Does It (and Batch-Exporting Many Projects)

Where labels live

The split rule

Pitfalls

Giving the pieces names players can read

Batch: many projects, one worker

What is free and what isn't

Testing

Try it

Takeaways

How to Open Outlook PST and OST Files Without Outlook

What PST and OST files are

Option 1: Use Outlook anyway (if you have access)

Option 2: libpff / pffexport (Linux, macOS)

Option 3: readpst → MBOX → Thunderbird

Option 4: Browser-based viewers

Step-by-step: which path should you take?

Wrapping up

Parsing multi-gigabyte Outlook PST files in the browser

The constraint that shapes everything

One method to intercept

The reader: 64 KB pages, LRU-capped

If you're in Node, you don't need any of this

What this doesn't solve

Shopify Markets CSV Price Updates: A Safer Way to Verify Catalog Imports

Why a successful import is not proof

A safer workflow

1. Save a baseline

2. Use the target catalog's own template

3. Normalize numbers before checking catalog behavior

4. Compare identities and counts

5. Test a small, multi-variant sample

6. Verify the result in the target catalog

7. Keep a rollback path

The practical boundary

Bulk Update Shopify Product Descriptions and Images Without Blank Overwrites

1. Start with a fresh Shopify export

2. Generate the repeated description in a spreadsheet

3. Avoid the blank-column trap

4. Treat images as a separate decision

5. Pilot before the full catalog

A Safer Way to Bulk-Update Shopify Product Descriptions by CSV

1. Start with a dated baseline

2. Generate descriptions in a separate column

3. Trim the import file

4. Treat images as a separate job

5. Run a preflight before production

6. Verify after import

Shopify CSV Cost per Item: Audit It Before You Create a Purchase Order

1. Start with a fresh product export

2. Check identity before checking the numbers

3. Review Cost per item beside Variant Price

4. Separate standing cost from the PO cost

5. Test the smallest safe change

What this workflow does not do

Shopify CSV Files Over 15MB: Split by Product Handle, Not Row Count

What `<input accept=".pst,.ost,…">` does on iOS

Why not just `fetch()` every `<img>`?