DEV Community: renomeeai

How I Built an AI File Renamer with FastAPI + Electron (and Why Not Tauri)

renomeeai — Mon, 26 Oct 2026 10:45:11 +0000

I had a folder with 2,000 files named things like IMG_8842.jpg, document(3).pdf, and Screenshot 2026-08-02 145321.png. I knew exactly what was in each one — the day I saved them. Two weeks later, I had no idea.

Writing regex felt like overkill. Manual renaming was out of the question. So I built RenomeeAI: an AI-powered desktop app that reads what's inside a file — its text, metadata, even EXIF data — and generates a meaningful filename based on what you tell it you need.

Here's what I chose to build it with, and why.

The Problem I Was Solving

Most file renaming tools work on existing filenames. They let you find-and-replace, add prefixes, or reformat dates — but only from information already in the name.

The real problem is different: the useful information is inside the file.

A screenshot of a payment failure contains an order number and error code — but the filename is just a timestamp.
A downloaded PDF report has a title and publisher on page one — but the filename is document.pdf.
A photo taken on a trip has GPS coordinates and camera settings in its EXIF data — but the filename is IMG_8842.jpg.

Traditional batch renaming tools can't help here. You'd need to open each file, read it, extract the relevant info, and rename it manually. That's exactly the slow, repetitive work AI is good at replacing.

What I needed was a tool that could:

Read the content or metadata of a file
Understand what the user actually wants from a simple description
Generate a clean, searchable filename — not a template, but a real decision

Why a Desktop App (Not a Web App)?

My first instinct was to build a web app. It's faster to ship, easier to share, and works on any device.

But three things pushed me toward a desktop app:

Privacy. Users are renaming real files — invoices, legal documents, personal photos. Uploading them to a server, even temporarily, felt like a non-starter. A local app processes everything on-device.

File system access. The browser's File System Access API has real limitations: no recursive folder traversal, no write access outside user-selected directories, no background processing. Electron gives you full fs access with no restrictions.

Native UX. Drag-and-drop from the file explorer, right-click context menus, system tray, file associations — these make a file utility feel like a real tool, not a workaround.

Architecture Overview

The app is split into two layers:

Electron handles the UI, file picker dialogs, and local system integration. It communicates with the backend over a local HTTP connection on a fixed port — simple, debuggable, and decoupled.

FastAPI handles everything AI-related: OCR, EXIF extraction, LLM calls, and the actual file rename operations. Python was the natural choice here — the AI/ML ecosystem lives in Python, and keeping all the smart logic in one place makes it easier to reason about.

The two layers are intentionally independent. You could swap the Electron frontend for a CLI or a web UI without touching the backend.

Why FastAPI for the Backend?

I considered Flask and a Node.js backend. Here's why I landed on FastAPI:

	FastAPI	Flask	Node/Express
Native async	✅	⚠️ requires workarounds	✅
AI/ML library ecosystem	✅ Python	✅ Python	❌ limited
Auto-generated API docs	✅	❌	❌
Type safety (Pydantic)	✅ built-in	❌	⚠️ optional

The async support matters more than it might seem. LLM API calls can take 2–10 seconds. If you're processing a batch of 50 files, you want those calls running concurrently, not queued. FastAPI's async/await model handles this cleanly without extra libraries.

Pydantic models also made request validation effortless — when Electron sends a rename request with file paths and user intent, FastAPI validates and parses it automatically.

Why Electron (Not Tauri, Not PyQt)?

This is the question I get most often, so let me be direct.

Electron vs. Tauri

Tauri is excellent for apps where Rust can do the heavy lifting. For an AI tool with a Python backend, the story gets complicated:

Tauri's backend is Rust. My AI logic is Python. Bridging them means running a Python subprocess and managing IPC between Rust and Python — two layers of complexity instead of one.
Electron's Node.js layer can spawn a Python process with child_process in a few lines, communicate over localhost HTTP, and shut it down cleanly on exit. It's boring in the best way.
Yes, Electron bundles Chromium and ships a larger binary (~120MB vs ~10MB for Tauri). For a productivity tool where users install once and use daily, that's an acceptable tradeoff.

Electron vs. PyQt / Tkinter

I considered keeping everything in Python with PyQt, but ruled it out quickly:

Web component libraries (React, shadcn/ui, Tailwind) give far more UI flexibility than Qt widgets.
The frontend can be worked on independently by someone who doesn't know Python.
Hot reload during development is significantly better with Vite + React than with PyQt.

Why Not Pure Electron (No Python)?

Node.js doesn't have mature, production-ready libraries for local OCR and LLM integration that match Python's ecosystem. The moment you need pytesseract, pdf2image, or direct Volcengine SDK calls, Python becomes the obvious choice.

The AI Layer: From Raw Data to Meaningful Names

This is the part that makes the app actually useful — and it's simpler conceptually than it sounds.

When a user selects files to rename, each file arrives at the AI layer with three types of raw data:

OCR output — text extracted from images or PDFs (what's visually on the page)
File metadata — original filename, size, modification date, directory path
EXIF data — for photos: camera model, capture time, GPS coordinates, aperture

On its own, this data is noisy and unstructured. The user's natural language input is the missing piece. When someone says "rename these invoices by supplier name and date" or "keep only the paper title and year", they're providing the selection criteria that transforms raw data into a specific filename.

The AI's job is to bridge these two sides: take heterogeneous file data on one end, take a plain-language intent on the other, and produce a clean, targeted filename. No regex. No template syntax. Just a description of what you want.

The AI doesn't rename files — it converts messy, heterogeneous data into the filename the user already had in mind but couldn't express as a rule.

This is the fundamental shift from traditional renaming tools. Instead of asking "what rule should I apply?", the user asks "what do I want these files to be called?" — and the answer is just a sentence.

Try It / What's Next

RenomeeAI is available for macOS and Windows. If you're dealing with folders full of screenshots, downloaded PDFs, or unorganized photos, it's worth a look.

👉 renomeeai.com (replace with real URL)

The next major feature on the roadmap is Google Drive integration — renaming files directly in the cloud without downloading them first. After that, deeper EXIF-based workflows for photographers.

If you've built something similar — or have strong opinions about Electron vs. Tauri for Python-heavy apps — I'd love to hear your take in the comments.

Why File Renaming Is Still a Hard Problem (And How AI Changes It)

renomeeai — Fri, 20 Mar 2026 01:05:10 +0000

Why File Renaming Is Still a Hard Problem (And How AI Changes It)

If you've ever downloaded 200 research papers with random filenames like 1234-abcd-5678.pdf, or inherited a folder of client photos labeled IMG_0001.jpg through IMG_2847.jpg, you know the pain.

File naming chaos isn't new. What's changed is how we solve it.

The Problem: Naming Isn't About Filenames

For decades, we've treated file renaming as a string manipulation problem:

Bash scripts: for f in *.jpg; do mv "$f" "${f%.jpg}_renamed.jpg"; done
PowerShell: Get-ChildItem | Rename-Item -NewName {$_.Name -replace 'old','new'}
Regex tools: s/(\d{4})-(\d{2})-(\d{2})/\2-\3-\1/g

These work... if you know exactly what pattern you're looking for.

But here's the real problem: filenames don't tell you what's inside the file.

You can't write a regex to rename report.pdf to Q3_Sales_Analysis_2024.pdf because the information isn't in the filename - it's buried in page 1, paragraph 2 of the PDF itself.

Traditional Solutions: Rule-Based vs. Context-Based

Rule-Based Approach (Traditional)

# Example: Add date prefix to all files
import os
from datetime import datetime

for file in os.listdir('.'):
    new_name = f"{datetime.now().strftime('%Y%m%d')}_{file}"
    os.rename(file, new_name)

Pros: Fast, predictable, deterministic

Cons: You need to know the pattern in advance. No content awareness.

What We Actually Need: Context-Based Renaming

Rename PDFs based on their title metadata or first heading
Sort photos by EXIF timestamps and camera model
Organize contracts by extracted party names and dates
Clean up music files using ID3 tags (artist, album, year)

The information exists - it's just trapped inside the files.

Why This Is Hard (Technically)

Let's break down what's needed for "smart" file renaming:

1. Content Extraction

Different file types require different parsers:

PDF: Text extraction (pdfjs-dist), metadata reading, OCR for scanned docs
Images: EXIF data parsing (exif-js), OCR for text in images
Office files: Document properties (docx → mammoth.js, xlsx → xlsx)
Audio/Video: Metadata tags (ID3, MP4 atoms)

2. Intent Recognition

Users don't speak in code. They say:

"Rename these photos by date and camera model"

You need to map this to:

{
  pattern: "{EXIF.DateTimeOriginal}_{EXIF.Model}_{index}",
  dateFormat: "YYYYMMDD_HHmmss",
  indexStart: 1,
  indexPadding: 3
}

3. Safety & Preview

Batch operations are dangerous. You need:

Preview before execution
Conflict detection (duplicate names)
Rollback/undo capability

No wonder most developers just write throwaway scripts instead of building reusable tools.

How AI Changes the Game

AI - specifically Large Language Models (LLMs) - solve the intent recognition and content understanding problems simultaneously.

The Traditional Approach (Limited)

User: "Rename PDFs by their titles"
  ↓
Apply generic naming pattern
  ↓
Result: generic_001.pdf, generic_002.pdf... (not helpful)

Problem: Without seeing the actual content, you can only use filename patterns.

The Content-Aware Approach (What We Built)

User: "Rename PDFs by their titles"
  ↓
AI analyzes intent and extracts relevant content
  ↓
Frontend extracts metadata and text locally
  ↓
AI generates smart renaming logic
  ↓
Result: Deep_Learning_in_Computer_Vision.pdf

This content-aware architecture works by:

Understanding what the user wants to achieve
Extracting only the necessary information from files
Generating rename operations based on actual content

Real-World Implementation (AI-Rename Case Study)

We built Renomee AI using this approach. Here's what it supports:

File Types & Extractable Fields

File Type	What We Extract	Use Case
PDF	Title, author, subject, text preview (first 1000 chars), headings	Academic papers, reports, contracts
Images	EXIF (date, camera, GPS, settings)	Photography workflows, asset management
Office Docs	Document title, headings, text preview	Business documents, legal files
Audio	ID3 tags (artist, album, year, genre)	Music library organization
Video	Resolution, duration, codec, FPS	Media asset management
Text Files	Content preview, Markdown headings, JSON keys	Code repos, note-taking

Example Interactions

PDF Renaming (Content-Aware)

User: "Rename these research papers by their titles"

AI extracts:
- paper1.pdf → metadata.title = "Attention Is All You Need"
- paper2.pdf → metadata.title = "BERT: Pre-training of Deep Bidirectional Transformers"

Result:
- Attention_Is_All_You_Need.pdf
- BERT_Pre-training_of_Deep_Bidirectional_Transformers.pdf

Photo Organization (EXIF-Based)

User: "Sort wedding photos by time and add sequence numbers"

AI extracts EXIF:
- IMG_1427.jpg → DateTimeOriginal = 2024-08-15 14:30:22
- IMG_1428.jpg → DateTimeOriginal = 2024-08-15 14:31:05

Result:
- 20240815_143022_001_Wedding.jpg
- 20240815_143105_002_Wedding.jpg

Contract Management (Text Extraction)

User: "Rename contracts by party names and date"

AI extracts from PDF text:
- contract.pdf → "Party A: XYZ Corp, Date: 2024-03-16"

Result:
- XYZ_Corp_20240316_Service_Agreement.pdf

Technical Architecture Deep Dive

Architecture Overview

┌─────────────────────────────────────────┐
│  Desktop Application                    │
│  ├─ User Interface                      │
│  ├─ Content Extraction (Local)          │
│  │   ├─ PDF parsing                     │
│  │   ├─ EXIF reading                    │
│  │   ├─ Document metadata               │
│  │   └─ Audio/Video tags                │
│  └─ File Operations                     │
└─────────────────────────────────────────┘
            ↓
┌─────────────────────────────────────────┐
│  AI Analysis Layer                      │
│  ├─ Intent Understanding                │
│  ├─ Content Processing                  │
│  └─ Rename Logic Generation             │
└─────────────────────────────────────────┘
            ↓
┌─────────────────────────────────────────┐
│  Preview & Confirmation                 │
│  ├─ Before/After Comparison             │
│  ├─ Conflict Detection                  │
│  └─ Batch Execution                     │
└─────────────────────────────────────────┘

Why Local Extraction Matters

Privacy: Most file content (Office documents, text files, EXIF data) is extracted directly on your computer and never leaves your machine. Only when OCR is needed (scanned PDFs, image text recognition) are files processed on secure servers - and only with explicit user consent.

Performance: Extracting metadata from 1000 photos takes just seconds locally, making the entire process feel instant.

How Content Extraction Works

When you give an instruction like "Rename PDFs by their titles", here's what happens:

AI analyzes your request and determines it needs PDF title information
Local extraction runs - the app reads PDF metadata and text directly on your computer
AI receives the content and generates appropriate rename operations
You preview the changes before confirming

This all happens in seconds, with most processing done locally for speed and privacy.

Example Flow

// User selects files and gives instruction
User instruction: "Rename PDFs by their titles"

// App extracts content based on user's needs
Extracted data:
- paper1.pdf → Title: "Attention Is All You Need"
- paper2.pdf → Title: "BERT: Pre-training..."

// AI generates rename operations
Proposed changes:
- paper1.pdf → Attention_Is_All_You_Need.pdf
- paper2.pdf → BERT_Pre-training_of_Deep_Transformers.pdf

// User confirms and executes
[Rename] [Cancel]

Comparison: AI vs. Traditional Tools

Feature	Bash/PowerShell	GUI Tools (Everything, Bulk Rename)	AI-Rename
Learning Curve	High (regex, scripting)	Medium (understand UI patterns)	Low (natural language)
Content Awareness	❌ (filename only)	⚠️ (manual preview)	✅ (auto-extract)
Flexibility	✅ (unlimited)	⚠️ (predefined rules)	✅ (natural language)
Safety	❌ (easy to overwrite)	✅ (preview mode)	✅ (preview + undo)
Batch Operations	✅ (script loops)	✅ (built-in)	✅ (conversational)
Cross-Platform	⚠️ (shell-specific)	⚠️ (Windows/macOS separate)	✅ (Electron)

Use Cases: Who Needs This?

1. Academic Researchers

Pain: 800+ papers with random download names (1234-5678-abcd.pdf)

Solution: "Rename by PDF title and author"

Result: Attention_Is_All_You_Need_Vaswani_2017.pdf

2. Photographers/Designers

Pain: Client projects with IMG_0001.jpg naming

Solution: "Sort by date, prefix with client name, add 3-digit sequence"

Result: ClientName_20240815_001.jpg

3. Legal/Finance Teams

Pain: Scanned invoices/contracts with generic names

Solution: "Extract vendor name, date, and amount from invoices"

Result: ACME_Corp_20240316_$5000_Invoice.pdf

4. Music Collectors

Pain: Downloaded albums with inconsistent naming

Solution: "Rename MP3s by Artist - Title format"

Result: The_Beatles_-_Hey_Jude.mp3

Challenges & Solutions

Challenge 1: Ambiguous Instructions

Problem: "Clean up these files"

Solution: AI asks clarifying questions:

"Do you want to remove spaces, add prefixes, or organize into folders?"

Challenge 2: Large Batches (1000+ files)

Problem: LLM context limits

Solution: Sample-based analysis:

Extract metadata from first 20 files
Infer pattern
Apply to all files

Challenge 3: Naming Conflicts

Problem: Multiple files want the same name

Solution: Auto-append sequence numbers:

Report_2024.pdf
Report_2024_(1).pdf
Report_2024_(2).pdf

Future Directions

1. Smarter Content Understanding

Visual Analysis: Rename images by detected objects ("Dog_Beach_Sunset.jpg")
Audio Transcription: Rename podcasts by topic discussed
Video Analysis: Extract chapter titles from videos

2. Learned User Preferences

Over time, the AI can learn your naming patterns:

Preferred date formats (YYYY-MM-DD vs. DD/MM/YYYY)
Separator preferences (underscores vs. hyphens)
Capitalization rules
Common prefixes/suffixes

This means less manual instruction needed for repeat tasks.

3. Cross-App Integration

Future versions could offer API access, allowing other applications to leverage the same intelligent renaming capabilities - imagine this built into your file manager, cloud storage, or DAM system.

Try It Yourself

Want to experience content-aware file renaming? Here's what you can do:

Option 1: Use AI-Rename (Free Trial)

Download: Renomee AI homepage
20 free operations daily
No signup required

Conclusion: From Rule-Based to Context-Based

File renaming stopped being a "hard problem" once we shifted from:

Pattern matching → Content understanding
Fixed rules → Natural language instructions
String manipulation → Semantic analysis

AI didn't just make renaming faster - it made it smarter. Instead of writing scripts to handle edge cases, we describe what we want and let the AI figure out the "how."

If you've ever spent an hour writing a bash one-liner to rename files, only to realize it broke on filenames with spaces... this is for you.

What's your file naming horror story? Share in the comments - and let's see if AI can solve it! 👇

Why Bing Is Stricter Than Google About URL Consistency — Technical SEO Deep Dive

renomeeai — Mon, 09 Feb 2026 07:22:05 +0000

While testing URL canonical behavior, I ran into an indexing conflict on a live tool page:
https://xiaojingxiu.com/image-to-pdf/

Different URL variants (with and without trailing slash) were both accessible, which led Bing to delay canonical selection and indexing.

I ran into an unexpected behavior difference between Google and Bing:
Bing is far more strict about URL canonical consistency than Google.

Google often auto-clusters inconsistent URLs.
Bing frequently delays canonical selection until signals are fully aligned.

This post documents a real technical SEO debugging case and the exact configuration fixes that resolved delayed indexing.

Symptom: Crawl OK — Not Indexed

In Bing Webmaster Tools:

Crawl: success
Fetch: success
Indexing allowed: yes
Canonical: not selected
Index status: pending

But Google indexed the same page within days.

The affected test URL in this case:

https://xiaojingxiu.com/image-to-pdf/

The page was reachable, fast, and content-complete — but canonical signals were inconsistent.

Root Cause: Multi-Layer URL Inconsistency

Bing evaluates canonical signals across multiple technical layers:

Layer	Must Match
Sitemap URL	exact
Canonical tag	exact
OG:url	exact
Internal links	exact
Redirect target	exact
IndexNow submission	exact

Even small differences like:

/image-to-pdf
/image-to-pdf/

are treated as separate candidates until proven otherwise.

Google clusters faster.
Bing waits longer.

Real Configuration Audit Example

Here is a real mismatch pattern found during audit:

Config Item	State	Risk
Sitemap.xml	no trailing slash	⚠️
Canonical	no trailing slash	⚠️
OG:url	no trailing slash	⚠️
Internal links	mixed	⚠️
robots.txt sitemap	correct	✅
Server redirect	missing	❌ critical

Result:

Canonical ambiguity
Duplicate candidates
Bing Delayed index decision

Why Trailing Slash Matters More for Bing

Google behavior:

/page
/page/
→ merged quickly

Bing behavior:

/page
/page/
→ evaluated separately first

If your signals disagree, Bing postpones canonical selection.

That postponement = indexing delay.

Required Fix Set (Production Checklist)

Choose one canonical format. Example:

https://xiaojingxiu.com/image-to-pdf/

Then enforce everywhere.

Canonical Tag

<link rel="canonical" href="https://xiaojingxiu.com/image-to-pdf/" />

OG URL

<meta property="og:url" content="https://xiaojingxiu.com/image-to-pdf/" />

Sitemap Entry

<loc>https://xiaojingxiu.com/image-to-pdf/</loc>

Never mix slash variants inside sitemap.

Server Redirect Rule (Critical)

Nginx example:

rewrite ^([^.]*[^/])$ $1/ permanent;

This forces:

/image-to-pdf → /image-to-pdf/

Return code must be:

301 or 308

301 and 308 are both ok, but 301 is the better.

Internal Link Hygiene

Avoid mixed references like:

/image-to-pdf

Use only:

/image-to-pdf/

Consistency reduces canonical conflict probability.

IndexNow Submission Discipline

Submit only canonical form:

https://xiaojingxiu.com/image-to-pdf/

If you submit both variants, you recreate ambiguity.

Validation Method

After fixes, verify with:

curl -I https://site/page

Expected:

301 → canonical

And page source must show:

canonical = sitemap = og:url = internal link

All identical.

Observed Result After Fix

After normalization:

Bing canonical field populated
Duplicate candidate removed
Indexing started within crawl cycle

Canonical detection was the turning point signal.

Practical Takeaway

For Google:

URL consistency = best practice

For Bing:

URL consistency = indexing prerequisite

If launching new tool or SaaS pages, normalize URL format before:

sitemap submission
IndexNow push
external backlinks

It prevents crawl budget waste and canonical delay.