Disclosure: I'm part of the team that builds Postwash. Postwash is an independent tool and is not affiliated with X Corp.

1. Scan and preview before anything is deleted

A cleanup starts with a scan, not a delete. You pick what to look at (posts, replies, reposts, likes or bookmarks) and narrow it with filters: date (older than 30 days, 90 days, 6 months, 1 year, or a custom range), words, likes or views, and media. The scan only builds a list. Every item shows its date, text and engagement, and you can untick or protect anything you want to keep. The pinned post is left alone.

The point is simple: a destructive operation should have a reviewable plan before it runs.

2. Backup first, and refuse to run without it

Before the first deletion, Postwash saves a CSV or JSON file with the text and details of everything that is about to go to your Downloads folder. If that file cannot be saved, nothing is deleted. A backup that is "best effort" isn't a backup, so the delete step depends on it succeeding.

Scheduled cleanups (daily or weekly, for example posts older than 30 days every week) follow the same rule: each run saves its own backup first.

3. Don't trust the success response: verify every deletion

A delete request can come back looking successful when the post is still there. If a tool counts responses instead of results, its "done" number is wrong and you only find out later.

Postwash asks X again after each deletion and counts the item only when it is really gone. The final report splits results into deleted, already gone and failed, and the full activity log can be exported as CSV.

4. Pace yourself and respect the rate limit

Hammering an API is the fastest way to get stopped halfway. Postwash has three paces (gentle, balanced and fast) with random pauses between actions. It follows X's rate-limit counter, slows down before the limit runs out, and stops by itself if X pushes back, instead of retrying in a tight loop.

5. Going past what the timeline shows

The timeline only reaches back so far, roughly 3,000 posts. For older history, Postwash can import your X data archive (tweets.js and like.js) and delete by ID. The archive files are read on your computer and never uploaded.

6. No password, no server

Postwash works through the X session that is already open in your browser. You sign in to the extension with Google, it never asks for your X password, and your posts are read on your device rather than sent to a server.

Try it

Postwash is free, works in 50+ languages, and runs in Chrome:

• Postwash on the Chrome Web Store
• Full guide and FAQ
• Video walkthrough on YouTube

If you have built something similar, I'd like to hear how you handled verification and rate limits.

Here are the six places I check, in the order I check them.

1. Response headers (Network tab)

Open DevTools, go to the Network tab, reload, and click the first document request. Look at the response headers:

• server often names the web server or edge: nginx, Apache, cloudflare, Vercel, Netlify.
• x-powered-by can reveal the backend, for example PHP/8.2 or Express. Many sites remove it, but plenty don't.
• Platform-specific headers are a strong signal: x-vercel-id, x-nf-request-id (Netlify), cf-ray (Cloudflare), x-shopify-stage or x-shopid (Shopify).

2. The HTML source

Press Ctrl+U (or Cmd+Option+U on a Mac) and search the source:

• <meta name="generator"> is the easiest win. WordPress, Wix, Hugo, Jekyll, Ghost and many others write their name and sometimes their version here.
• /wp-content/ or /wp-includes/ in asset paths means WordPress, even if the generator tag was removed.
• __NEXT_DATA__ in a script tag means Next.js. __NUXT__ means Nuxt. id="___gatsby" means Gatsby.
• cdn.shopify.com in image or script URLs means Shopify.

3. Global variables (Console tab)

Frameworks and libraries often leave objects on window. In the Console, try:

!!window.React || !!document.querySelector('[data-reactroot]')
!!window.__NEXT_DATA__
!!window.Vue || !!window.__VUE__
!!window.jQuery && jQuery.fn.jquery
!!window.ng

The jQuery line returns the version number, which is handy when you're checking for outdated libraries.

4. Script and asset file names (Sources or Network tab)

Bundle names give a lot away. _next/static/chunks/ is Next.js, /_nuxt/ is Nuxt, /assets/index-[hash].js is a common Vite build pattern, and /static/js/main.[hash].js is classic Create React App.

5. Third-party requests

Filter the Network tab by JS or by domain and you'll see the marketing and analytics stack:

• googletagmanager.com/gtag/js or /gtm.js for Google Analytics and Tag Manager
• connect.facebook.net for the Meta Pixel
• static.hotjar.com for Hotjar
• js.stripe.com for Stripe
• widget.intercom.io or embed.tawk.to for live chat

6. Cookies (Application tab)

Under Application > Cookies, names are often branded: _ga (Google Analytics), _fbp (Meta Pixel), _shopify_y (Shopify), wordpress_logged_in_ (WordPress), PHPSESSID (PHP sessions), laravel_session (Laravel).

Putting it together

No single clue is proof. Headers can be stripped and generator tags removed, so I look for two or three signals that agree. A cf-ray header plus /wp-content/ paths plus a _ga cookie tells a pretty complete story: WordPress behind Cloudflare with Google Analytics.

When you do this a lot

If you check sites daily, for client audits, competitor research or sales prospecting, clicking through four DevTools tabs gets old. I built a free Chrome extension, Detechtor AI, that reads these same kinds of signals and shows the detected stack in one click. Full disclosure: I'm the developer. The manual method above works just as well when you only need it once in a while, and it's worth knowing either way, because it tells you why a tool says what it says.

What's the strangest stack you've uncovered this way? I'd like to hear it in the comments.