DEV Community: dylan yu

January 2027 archives Snapchat Memories. It does not delete them.

dylan yu — Tue, 29 Sep 2026 10:36:14 +0000

Snapchat's Help Center does not name a day when Memories are deleted. The dated change is an archive, and it does not start before January 2027.

This note is the checklist I use before that month: who is affected, what "archived" means in Snap's own wording, and how to get a My Data ZIP onto a computer while the download link still works. It is not a Snapchat login tool, and it is not affiliated with Snap Inc.

What Snap actually dated

On How do I manage my Memories storage?, Snap says it will not automatically delete Memories because you do not upgrade.

Starting in January 2027, and not before, Memories that are more than one year old and are not part of your oldest 5 GB are archived. They stay stored. In the app they show up as thumbnails. Opening, editing, or sharing an archived Memory needs a storage plan, or a download you already have.

Two groups stay open without that plan:

Memories saved within the last year
Your oldest 5 GB of Memories

People under 5 GB are outside this change. Snap also says the app will warn you before the archive applies to your account. The September 26, 2025 newsroom post about Memories Storage Plans announced the 5 GB cap, 12 months of temporary storage for the overflow, and a download to your device. That post does not name a deletion date either.

So "when is Snapchat deleting memories?" does not have a deletion date to put on a calendar. The date that does exist is the start of the thumbnail archive.

Request the export before you need it

The Help Center lists the download as the way to open Memories outside the app.

Sign in at accounts.snapchat.com, or open Settings and choose My Data.
Turn on Export your Memories. If you only want the camera roll archive, use Request Only Memories.
Pick a date range. A longer range takes longer to build.
Confirm the email address that should receive the ready notice.
Submit, then wait. Snap says it tries to deliver within 7 days. A large Memories export can take longer, and it can arrive as more than one ZIP.
Download on a computer. The link does not stay valid forever; if it expires, submit a new request.

My Eyes Only is not in that export. If something important is locked there, unlock it and move it into regular Memories before you submit.

What the ZIP is missing

The export gives you the media files plus memories_history.json. The capture time and location are in that JSON. They are not written into the photo or video file as EXIF. A gallery that sorts by file date will look wrong even though the history file is correct.

That is a file-format gap, not a sign that Snap deleted the Memory. I walk through the archive date and the local ZIP read on When is Snap deleting memories?. The page reads the official My Data ZIP in the browser. It does not log into Snapchat.

A few checks after the files are on disk:

Open index.html from the export and confirm Memories is in the left navigation before you assume the ZIP is empty.
Keep every part if Snap split the download. A partial folder will look like missing months.
Compare a handful of items against memories_history.json before you delete anything inside the app.
Do not treat a camera-roll save of a few Snaps as a substitute for the My Data export. The in-app save is one Memory at a time and does not rebuild the history file.

What I would not wait on

Archived does not mean deleted, and a thumbnail you can see in January 2027 is not the same as a file you can open. If the account is over 5 GB, the export is the copy that still opens without a storage plan. Request it while the queue is normal, download it when the email arrives, and keep the ZIP until you have checked the dates in the history file.

If Snap publishes an exact calendar day later, it will be on that Help Center page. Until then, January 2027 is the start of the archive, not a deletion date.

Archive, plan, and a local copy are three different things

A storage plan keeps the overflow open inside Snapchat. It does not put a dated copy on your disk. The My Data ZIP does the opposite: it is a copy you control, and it does not change what the app will archive in January 2027.

If you only need a few photos, saving them to the camera roll is enough. If you need the year-by-year set, use the export. After the files are local, sort them with the history JSON rather than the file modified time. The modified time is when the ZIP was unpacked, not when the Snap was taken.

I would also leave the Snapchat account logged in on a computer until the email arrives. The ready notice is easy to miss, and a second request is slower than downloading the one you already have.

Why exported Snapchat Memories lose their dates, and how to fix the EXIF

dylan yu — Fri, 25 Sep 2026 13:00:23 +0000

Snapchat's My Data export gives you the photos and videos. It does not give photo apps a capture date they can sort on. The files arrive, the years collapse onto the day you unzipped the ZIP, and the map stays empty even when Snapchat knew where the Snap was taken.

This is a metadata mismatch, not a failed download. The capture time is in the export. It is just not in the field Google Photos and Apple Photos read.

What the ZIP actually contains

Request the export from accounts.snapchat.com: My Data, turn on Export your Memories, then submit. Snap's help page says they aim to deliver data within 7 days, and that large downloads can take longer. Download every part of the ZIP. A single part, or the HTML index without the media files, is not the whole library.

Inside a current export you should find media files plus memories_history.json. The JSON row for a Snap carries the capture time as a UTC timestamp, in a shape like 2017-04-03 22:11:04 UTC. Newer exports also split a memory into a camera file whose name ends in -main and a transparent -overlay.png for the caption or sticker. Older exports use a memories/ folder and a date prefix on the filename.

None of those are EXIF. Unzipping also stamps the filesystem "modified" time as today on macOS and Windows. Finder can look correct if you sort by filename and wrong if you sort by Date Modified. Photo libraries ignore both the filename and that filesystem time.

Which fields photo apps actually read

For a JPEG, Google Photos and Apple Photos sort on EXIF:

DateTimeOriginal
CreateDate (also called DateTimeDigitized in some tools)
GPSLatitude and GPSLongitude, if you want the map

For an MP4, they read the QuickTime creation time stored in the mvhd, tkhd, and mdhd atoms. A date that exists only in a sidecar JSON never reaches those atoms.

So the fix is a copy, not a guess. Read the UTC time from the JSON row that matches the file. Write that same instant into the photo or video. If the JSON location is missing or N/A, leave GPS empty. Do not invent coordinates.

EXIF wants YYYY:MM:DD HH:MM:SS with colons in the date. The JSON value 2017-04-03 22:11:04 UTC becomes 2017:04:03 22:11:04. Keep the clock time in UTC when you write QuickTime fields, then check the result in Photos. A one-hour shift usually means the app displayed local time, not that the day was wrong.

Check one file before you batch

Install ExifTool if you want to do this by hand. On one JPEG:

exiftool -DateTimeOriginal -CreateDate -GPSLatitude -GPSLongitude photo.jpg

If DateTimeOriginal is missing, or it shows the day you downloaded the ZIP, the file still has the export stamp. After you copy the JSON time:

exiftool -DateTimeOriginal="2017:04:03 22:11:04" \
  -CreateDate="2017:04:03 22:11:04" \
  -ModifyDate="2017:04:03 22:11:04" \
  photo.jpg

Replace the timestamp with the value from that file's JSON row. ExifTool keeps the original bytes beside the file as photo.jpg_original unless you pass -overwrite_original.

For a video, tell ExifTool the value is UTC:

exiftool -api QuickTimeUTC=1 \
  -QuickTime:CreateDate="2017:04:03 22:11:04" \
  -QuickTime:ModifyDate="2017:04:03 22:11:04" \
  clip.mp4

Run the read command again. You want the year and day from the JSON, not today. Then import that one file into Google Photos or Apple Photos and confirm the library year before you touch the rest of the ZIP.

GPS is the same idea. The JSON line looks like Latitude, Longitude: 40.7128, -74.0060. West and south need the ref tags:

exiftool -GPSLatitude=40.7128 -GPSLatitudeRef=N \
  -GPSLongitude=74.0060 -GPSLongitudeRef=W \
  photo.jpg

Use the signs from your own row. A positive longitude is east (GPSLongitudeRef=E). If the row has no numbers, skip this. Filename-only dates do not contain a location.

Why a folder of files still goes wrong

Hand-editing a few dozen photos is realistic. A full Memories export is not, for three reasons that show up after the dates are fixed.

The overlay PNG is transparent. Photos apps paint transparency black, so importing -overlay.png alone produces a black card. The picture is the -main file. The caption lives in the overlay. You either composite them or keep the PNGs out of the library.

Long recordings are often several short MP4s that share an id. Dating each part puts them next to each other. Joining them into one clip is a separate step, and it still needs the same QuickTime dates on the output or the merged file falls back to today.

The JSON is usually in the first ZIP part. If you only downloaded a later part, you can have media with no timestamps to copy. Match the file name or id to a row before you write anything.

Doing that match, the EXIF write, the GPS write, and the overlay composite for every file is the tedious part. I use a browser tool that reads the official ZIP locally and writes DateTimeOriginal plus QuickTime creation time from memories_history.json, without uploading the photos: fix the dates on a Snapchat Memories export. The manual ExifTool path above is the same correction if you would rather script it yourself. A longer walkthrough of the field mismatch is on why exported Snapchat Memories show the wrong date.

After the files are dated

Import the corrected folder, not the raw unzip. In Google Photos, new uploads pick up DateTimeOriginal on the way in. Changing a file that is already in the library often means deleting that copy and uploading the corrected one. Apple Photos behaves the same way: the date is captured at import.

Do not rely on "Adjust Date and Time" in the Photos app for a whole year of Snaps. That shifts a selection by one offset. Memories span many years, each with its own timestamp in the JSON.

Two limits are worth knowing so you do not blame the EXIF write for them. Snapchat's export only includes Memories still on the account. A Snap you never saved, or one Snapchat has already removed, will not be in the ZIP. And from January 2027, Snap's help center says Memories older than a year that sit outside your oldest 5GB can be archived as thumbnails. Download those before you need a full-resolution file. Archiving is separate from the date bug: a file you already exported can still show today's date until the EXIF is written.

When you are done, spot-check the oldest year, a video, and one photo that had a location. If those three land on the right day, the copy from JSON to EXIF worked.

Three file jobs that keep breaking: image provenance, chat exports, and subtitle scripts

dylan yu — Thu, 17 Sep 2026 12:17:47 +0000

A lot of “AI tools” content is really about files. You generate or download something, then you need it in a format a teammate, a CMS, or a lawyer can actually use. Three jobs show up constantly in that gap:

What metadata is still inside an image after you export it?
How do you get a ChatGPT thread into Word without wrecking lists and code?
How do you turn an SRT file into a document someone can comment on?

They look unrelated until you put them on the same desk. Below is a practical workflow I use, plus the three small browser tools I keep for the last mile.

1. Images: EXIF is not the whole story

Stripping “metadata” usually means EXIF: camera model, GPS, dates. That is not enough anymore.

IPTC still carries captions, credits, and sometimes keywords that survive a “Save for web” pass.
C2PA (Content Credentials) is a signed provenance box. Some generators attach it; some editors leave it; some CDNs strip it. You cannot guess from the pixels.

If you publish product shots, screenshots, or user uploads, inspect the output file, not the editor UI. A pipeline can remove EXIF and still ship a C2PA manifest, or the reverse.

I keep a short inspector/remover walkthrough here: Remove AI Meta. Use it as a hygiene check. It does not make a file anonymous, and it does not prove a picture was or was not generated. If the file is going into news, legal, or a client archive, run a second inspector on the bytes you actually attach.

Checklist I use:

Re-download the file you will send (not the preview in the tab).
Confirm the format (JPEG vs PNG vs WebP); manifests do not travel the same way.
If you must keep provenance (newsroom, brand kit), do not strip C2PA just because a blog said “remove AI meta.”

2. ChatGPT → Word: paste is not an export

A long ChatGPT thread is a structured conversation: turns, lists, fenced code, tables. Word expects paragraphs, styles, and headings. Clipboard paste maps none of that reliably. You get:

collapsed lists
code that wraps into prose
lost speaker turns
smart quotes that break snippets

For notes, a client recap, or an internal archive, you want a .docx you can search and edit. That is the job of ChatGPT to Word: browser-side export with readable blocks instead of a blob of text.

Operational rules, not marketing:

Redact first. API keys, customer names, and internal URLs should not hit Word’s autosave or email. The exporter is not an access-control layer.
Skim headings after export. If the thread mixed several topics, split the document before you share it.
Do not treat the .docx as a source of truth for code; copy snippets back from the original fence if you will compile them.

3. SRT → Word: players are not editors

SRT is a player format: index, timestamp, one or two lines of text. Translators, teachers, and producers need comments, tracked changes, and a printable script. Dumping SRT into a text editor leaves timestamps glued to dialogue; dumping it into Word by hand is slow and error-prone.

SRT to Word turns cues into an editable document and keeps timing blocks readable where the converter supports it.

Things that actually break batches:

Encoding (UTF-8 vs UTF-16 vs a Windows code page)
Cues that wrap mid-sentence
Overlapping timestamps from auto-caption tools

After conversion, I always read the first ten and last ten cues before sending the file. If those look right, the middle is usually fine; if they do not, stop and fix encoding instead of “cleaning in Word.”

How these three fit together

A typical week for me looks like: generate or receive assets → inspect what the file still contains → put the language into Word so other people can work.

Job	Pain	File you want
Image / screenshot	Hidden provenance or leftover IPTC	A clean (or intentionally signed) image
Chat session	Unreadable paste	`.docx` with structure
Subtitles	SRT that nobody can comment on	`.docx` script

None of these replace a DAM, a subtitle suite, or a records policy. They are the 10-minute last mile so you are not fighting the wrong format.

If you only bookmark one starting point for “browser tools grouped by job,” I keep a broader index at Web Tools List—but the three links above are the ones I actually open for this file workflow.

Finding the track used in an Instagram Reel

dylan yu — Thu, 17 Sep 2026 12:12:39 +0000

Reels often show a clipped audio label that is useless if you want the original song, especially when the caption is a joke and the audio is a trend edit.

A dedicated search page that lets you work from clip, artist, or trend hints is faster than scrolling comments. That is the job of Reel Song Finder.

Results still depend on what Instagram exposes and on how heavily the audio was remixed. If you need a commercial license, confirm the recording with the rights holder after you identify the title.

A job-based directory for in-browser tools

dylan yu — Thu, 17 Sep 2026 12:11:09 +0000

Most “tool lists” dump hundreds of bookmarks in one pile. When you actually need to compress a PDF or generate a QR code, that pile is slow to scan.

I keep a smaller directory grouped by job, not by brand: generators, converters, editors, calculators, checkers, templates, and builders. Each entry is a browser workflow, so you are not installing a desktop app for a one-off task.

The live list is here: Web Tools List. If you maintain a similar index, the useful test is: can a stranger find the right tool in under a minute without knowing the product name?

I also keep a few short guides on PDF, image compression, and palette/QR generators on that site. Feedback on missing jobs is welcome.

A Practical Evidence-First Workflow for Troubleshooting Palworld Mods

dylan yu — Tue, 14 Jul 2026 09:13:54 +0000

When a Palworld Mod setup fails after an update, the instinct is often to disable Mods until the game starts again. That can produce a temporary answer, but it is a weak debugging method. It changes several variables at once, destroys evidence about the original state, and makes it easy to mistake correlation for a root cause.

A better approach is evidence-first troubleshooting: preserve what you can observe, distinguish facts from hypotheses, change one reversible thing, and record the result. This workflow is useful whether the problem is a startup failure, a loading issue, a missing feature, or a crash that appeared after a Mod or configuration change.

1. Why randomly disabling Mods is a weak debugging method

A large disable-and-retry pass can tell you that something in the removed set mattered. It cannot reliably tell you which item mattered, whether a configuration change was involved, or whether the next update will recreate the problem. It also makes it harder to return to the last known state.

Start instead by stating the symptom precisely: what action produces it, when it began, and what changed immediately before it. A precise symptom is not a diagnosis, but it gives the next test a purpose.

2. Preserve the current state before changing anything

Before editing, removing, or reinstalling, make a safe copy of the configuration you plan to touch. Record the current game version, UE4SS version, recently changed Mods, and the exact symptom in a short note. Do not publish raw logs, complete configurations, save files, credentials, tokens, or local paths while asking for help.

The point is not to create an archive of everything. It is to retain enough context to undo one experiment and compare its result with the prior state. If a change makes the problem worse, restore the copy rather than improvising a second change on top of the first.

3. What UE4SS.log can and cannot prove

A selected UE4SS.log can provide useful observations. It may show that the text resembles a UE4SS log, that a loading-style module name appears, or that an error-like entry was recorded. Those observations can help form a focused next check.

They do not prove that the loader version is valid, that a module fully loaded, that a particular Mod caused a crash, or that an absence of a matching line means the setup is healthy. Logs describe some observed events, not the full runtime state. Treat a notable line as a lead to verify against the current Mod documentation and one controlled retest.

4. What PalModSettings.ini can and cannot prove

A selected PalModSettings.ini may expose readable key/value structure, including fields such as ActiveModList or PackageName when they are present. That is valuable for answering narrow questions: is a package named in the selected settings file, and does the list match the state you believe you configured?

It cannot prove that the package exists on disk, is current, is compatible with the installed game version, or successfully loaded. A listed name is configuration evidence, not a runtime verdict. If the list looks unexpected, make one reversible correction, keep the backup, and test again.

5. What Info.json can and cannot prove

When a selected Info.json is a valid JSON object, it may contain declared package metadata, version text, server flags, or dependencies. This can help compare an author's stated requirements with the files you selected.

It still cannot prove installation, dependency satisfaction, compatibility, or successful loading. Invalid JSON, an empty file, or a different JSON shape should be treated as limited input, not an invitation to guess missing metadata. In troubleshooting, an explicit unknown is safer than a confident-looking assumption.

6. Separate observed facts from hypotheses

Write findings in two columns, even if only mentally. Observed facts are things the selected file visibly contains: a package name, a configuration entry, an error-like line, or invalid JSON. Hypotheses explain what those facts might mean: a version mismatch, a dependency issue, a stale setting, or a conflict.

Do not promote a hypothesis to a fact because it sounds plausible. For example, a module name in a log and a package name in settings may be related, but that relationship does not establish a unique crash cause. Keep the language honest: “needs checking,” “consistent with,” and “not confirmed” are useful debugging outcomes.

7. Make one reversible change at a time

Choose the smallest safe test that distinguishes between two hypotheses. That might mean restoring a known setting, temporarily removing one recently changed entry, checking the Mod author's current requirements, or testing a single version-aligned configuration. Make the change reversible and document exactly what changed.

Avoid changing the loader, multiple Mods, and configuration values in the same attempt. If the symptom disappears after three simultaneous changes, you have a working state but very little causal evidence. One controlled change creates a result you can learn from.

8. Re-test and record the result

Use the same reproduction step whenever possible. Record whether the symptom changed, stayed the same, or changed form. A result such as “no difference” is valuable: it rules down the tested hypothesis without claiming to solve the entire issue.

When the behavior changes, compare that single difference with your earlier facts. Then either verify the new hypothesis with another small test or stop when the current evidence is insufficient. Good troubleshooting has permission to pause rather than invent certainty.

9. Where a browser-local tool can help

I built TamerTools as a Public Beta structured first pass for this workflow. It reads only files you actively choose in the browser, processes them locally, does not upload analysis files, and requires no account. It currently supports UE4SS.log, PalModSettings.ini, and Info.json. It does not scan a complete game directory and it does not execute files.

The useful role of a tool here is organization: surface visible facts, deterministic checks, and unknowns so that the next reversible test is clearer. It is not a substitute for game updates, Mod-author instructions, or runtime verification. The project is available at TamerTools. Public documentation for its supported-file and privacy boundaries is available in the TamerTools GitHub repository.

10. Limitations and next checks

No file-based first pass can guarantee that it found every conflicting Mod or identify one unique root cause. A selected log can be incomplete, settings can be stale, metadata can be absent, and real runtime behavior can depend on information outside the three selected files.

The next checks are therefore practical: read current official game and Mod documentation, verify the versions you actually installed, preserve your backup, and use the result of each small test to choose the next one. If you share a problem publicly, share only an inspected, redacted summary rather than raw diagnostic material.

Disclosure: I used AI assistance to edit this article and reviewed the technical claims against the public documentation before publishing.

Use TamerTools as a structured first pass, then verify each hypothesis with one reversible change at a time.