Big ideas start
with useful tools.
PaperShift began with a practical question: why does a document that looks finished become difficult to edit the moment it arrives as a PDF?
02
03
04
05
06
07
Meet Ekansh
I'm Ekansh Pratap Singh, an MCA graduate and AI & Python developer with a foundation in web development, C, C++, JavaScript, APIs, and databases. My current focus includes Python, Generative AI, LLM applications, RAG, AI automation, and building practical web products. I enjoy turning ideas into clean, functional, responsive applications. My portfolio at epsingh.in is the best place to find my current work and background.
The idea behind PaperShift
PDFs are excellent for sharing a document whose appearance should stay consistent. They are less convenient when someone needs to change a sentence, reuse a table, update a heading, or adapt the content for another purpose. PaperShift is designed to make that first conversion step straightforward: upload, process, download, review.
The goal isn't to claim that a single algorithm can perfectly reconstruct every document. A PDF can contain independently positioned characters, vector artwork, scanned pages, unusual fonts, and complex multi-column layouts. An editable Word file uses a different layout model. A trustworthy product should explain those limits instead of pretending that every conversion is flawless.
Why the interface is quiet
The dark interface and restrained metallic accents are inspired by focused product landing pages: one clear task, generous spacing, visible status, and a direct path to the result. The visual design should support the utility rather than compete with it. On mobile, the upload action stays prominent, content stacks naturally, and the navigation remains accessible.
How this project is built
PaperShift uses FastAPI for request handling, PyMuPDF to inspect PDF text and styling, and python-docx to generate an editable DOCX. The code is separated into application logic, templates, static assets, and documentation. That structure makes it easier to introduce OCR, table recognition, background conversion jobs, object storage, and usage controls without rewriting the whole application. This reflects the approach I value in my wider work: understand the problem first, build a practical solution, then improve it through testing and iteration.
What comes next
- Optional OCR for scanned documents, with a clear processing status.
- More reliable table and reading-order reconstruction.
- Page-level comparison and conversion quality indicators.
- Asynchronous jobs for larger files and high traffic.
- Deployment-ready rate limiting, observability, and configurable retention.