DEV Community: Aditya Sorathiya

I built an E2EE paste utility with 12K users (1,800+ commits). Is a local HTML/CSS/JS Android wrapper a good idea?

Aditya Sorathiya — Mon, 28 Sep 2026 14:49:14 +0000

Hey DEV community! 👋

I'm a 10th-grade self-taught developer, and for the past several months, I've been working as a one-man army (handling coding, testing, DevOps, and SEO) on my project: PasteDB.

To give you an idea of the scale, the ecosystem currently spans across a web interface, an npm CLI tool (pastedb-cli), two SDKs (Node.js/Python), and a live VS Code Marketplace extension. The core repository alone has over 1,800+ verified commits, and we just crossed 12,000+ active users completely organically.

🚀 Our Current Tech Stack (Running at ₹0)

Because I am a student, I've architected everything to run smoothly on cloud free-tiers with a strict ₹0 maintenance budget:

Frontend: Vanilla HTML, CSS, JavaScript (Hosted on Netlify)
Backend: FastAPI / Python (Deployed on Render's free tier)
Database: MongoDB Atlas (Free tier cluster) + Cloudinary for images

🔐 The Core Problem & Features

PasteDB isn't just a standard text dump. It features client-side End-to-End Encryption (E2EE) where encryption keys never touch my database server. It also supports automated "Burn After Read" pastes, an in-viewer code execution engine, automatic rolling version control history (up to 10 versions), and a 3-finger gesture-based Nearby Transfer protocol and many more…

📱 The Upcoming Milestone: A Native Android App

Now that my 1st-term school exams are wrapping up, my next major goal during vacation is to launch an official PasteDB Android App.

Because I want to minimize development time, maintain our tight browser-side cryptographic logic, and ensure the app loads instantly on slow networks, I am planning to build a Local Hybrid Architecture.

Instead of pulling the UI over the internet, my plan is to:

Embed our exact web index.html, style.css, and crypto-heavy script.js files directly inside the Android project's assets/ folder.
Build a lightweight Kotlin wrapper using Jetpack Compose.
Use Android's view container to render the UI entirely from local disk storage via loadUrl("file:///android_asset/index.html").
Point all fetch requests in the JS script to the absolute Render URL of our FastAPI backend.

This means no web browser layout is involved for the user, and the application interface will load instantaneously without costing a rupee in frontend bandwidth.

🤔 My Question to Senior Engineers: Is this a good idea?

Since this is my first time deep-diving into Android deployment, I want to know your thoughts on this approach. Specifically:

Security & Cryptography: Our client-side E2EE relies entirely on browser-based JS crypto execution. Will loading these scripts locally via file:/// inside an Android WebView introduce any native sandbox security leaks or quirks?
Performance Constraints: Are there significant performance penalties for letting local vanilla JS handle DOM updates inside a Kotlin wrapper compared to writing a completely native Kotlin UI?
Hardware Access: Will the local asset container successfully allow hardware-level access if I request native Android permissions (like Location/Bluetooth for our Nearby Transfer feature, or Camera access for scanning QR codes)?

I'd love to hear your feedback, architectural warnings, or library recommendations (should I stick to standard Android WebViews, or explore engines like QuickJS for the crypto backend?).

Drop your advice in the comments below! 👇

Hardware Limits Couldn't Stop Me From Building PasteDB

Aditya Sorathiya — Wed, 23 Sep 2026 09:49:41 +0000

I built PasteDB, an open-source developer tool, largely using a damaged bleeding smartphone. This is the story of building software despite hardware limitations and why imperfect hardware doesn't have to stop you from learning, coding, creating and SHIPPING.

The real image today (23/9/2026)

The image was clicked with my father's phone

I searched “pastebin cli” on Google... and i got my project??? 🔎

Aditya Sorathiya — Sun, 20 Sep 2026 14:33:41 +0000

One of those small milestones that feels surprisingly big. 🚀

I searched Google for:

pastebin cli

And PasteDB CLI appeared on the first page of results.

Google is showing:

“PasteDB CLI – Pastebin Command Line Tool for Developers”

The result appears below Google's AI Overview.

PasteDB is an open-source developer-focused paste platform I've been building, and the CLI lets developers work with pastes directly from their terminal.

It supports things like:

Create pastes
Read pastes
Update pastes
Delete pastes
Explore pastes
Work with the PasteDB API directly from the terminal

What makes this milestone exciting to me isn't just seeing my project's name in Google.

It's that someone searching for a generic term like “pastebin cli” can potentially discover a project I built.

It's a small SEO/discoverability milestone, but for an indie/student developer, these little moments are really motivating. 😄

PasteDB:
https://pastedb.netlify.app

GitHub:
https://github.com/sorathiya903/pastedb

Have you ever had a project unexpectedly start appearing for generic searches? I'd love to hear about it.

The API Worked Locally. Then Production Broke It. 💀

Aditya Sorathiya — Wed, 16 Sep 2026 11:58:31 +0000

┌──────────────────────────────────────┐
│ 🧪 API HEALTH CHECK                  │
├──────────────────────────────────────┤
│                                      │
│ 💻 Local                             │
│    GET /api/test                     │
│    → 200 OK ✅                       │
│                                      │
│ ☁️ Production                        │
│    GET /api/test                     │
│    → 500 Internal Server Error 💀    │
│                                      │
└──────────────────────────────────────┘

And that's where the debugging began.

Locally, everything was working exactly as expected. The API responded correctly, the frontend connected, and there were no obvious errors. But after deployment, something had changed.

So what broke?

You know that feeling when everything works perfectly on localhost?

The API responds.
The frontend gets the data.
Authentication works.
You test it five times.

So you deploy it.

And suddenly:

💥 500 Internal Server Error

Nothing changed.

Except… everything.

The classic situation

During development, I had something like:

Frontend → localhost API → Database

I tested the endpoint and got exactly what I expected.

{
  "success": true,
  "data": "Hello from the API"
}

Perfect.

Then I deployed the backend.

Frontend → Production API → Database

And the frontend started throwing errors.

The worst part?

The API worked when I tested some endpoints manually.

That made it even more confusing.

So what actually changed?

A production environment isn't just your local computer moved to the internet.

There are a lot of things that can be different:

Environment variables
CORS configuration
Database connection strings
HTTPS vs HTTP
Allowed origins
File paths
Case-sensitive filenames
Dependency versions
Python/Node versions
Proxy configuration
Authentication cookies
API URLs
Deployment-specific filesystem behavior

One tiny assumption in development can become a production bug.

One of my favorite examples: environment variables

Locally, you might have:

API_URL=http://localhost:8000

Everything works.

But your deployed frontend might still be trying to call:

http://localhost:8000

From the user's browser, localhost means their computer, not your server.

So your API isn't even being contacted.

That bug can be surprisingly easy to miss if you're only testing locally.

Another one: CORS

You might test your frontend and backend locally with:

http://localhost:5500

and:

http://localhost:8000

Then production becomes:

https://myapp.com

and:

https://api.myapp.com

Your backend needs to know that the production frontend is allowed to make requests.

A configuration that worked locally isn't necessarily correct for production.

And then there's the database 😭

Your local machine might have:

mongodb://localhost:27017/mydb

Production obviously can't use your laptop's MongoDB.

So you replace it with a hosted database connection string.

Then you discover:

Authentication failed.

Or:

Connection refused.

Or:

Network access denied.

The API code itself might be completely fine.

The environment around it isn't.

The lesson I learned

When something breaks after deployment, don't immediately rewrite the endpoint.

First ask:

"What is different between local and production?"

I now mentally go through something like:

Environment variables
        ↓
API URL
        ↓
CORS
        ↓
Database
        ↓
Authentication
        ↓
Dependencies
        ↓
File paths
        ↓
HTTPS / proxy
        ↓
Production logs

Only after checking those do I start changing application code.

Production is a different environment

This is probably one of the biggest lessons I've learned while building web projects.

"It works on my machine" isn't the end of testing.

It's actually the beginning of a new type of debugging.

Local development tells you:

"The code can work."

Production testing tells you:

"The entire system works together."

And those are two very different things.

What's the strangest "works locally, breaks in production" bug you've encountered?

I'd love to hear the weird ones. 👇

My Computer Teacher Marked My Correct Answer Wrong — So I Investigated It

Aditya Sorathiya — Mon, 14 Sep 2026 16:32:49 +0000

My Computer Teacher Marked My Correct Answer Wrong — So I Investigated It

A few days before my Class 9 annual exams, something happened during a computer science test that I still remember.

It wasn't a huge incident. It was just one MCQ worth one mark.

But that one mark taught me something much more valuable: being a student doesn't mean you should stop questioning an answer when you have evidence that something is wrong.

Note: This story is completely unrelated to my PasteDB project. It is a personal experience from my Class 9 computer science test.

The 19/20

It was March, a few days before our Class 9 annual examinations.

Our computer science teacher conducted a 20-mark test containing 20 multiple-choice questions.

A few days later, we received our papers.

I got 19/20.

Everything looked normal until I reached Question 8.

The question was:

Which of the following is not a limitation of a mobile phone?

There were four options. I don't remember options A and B exactly, but the two relevant options were:

C. Memory

D. Network

I had selected D. Network.

But my answer had been marked wrong.

According to the answer key, C. Memory was considered correct.

I immediately wondered:

How could network not be a limitation of a mobile phone?

I decided to ask about it.

Going to the Staff Room

I took my computer paper and went to the staff room with two of my friends.

There were two teachers there — my computer teacher and my maths teacher.

One of my friends had come to discuss his maths paper. After his discussion was finished, he left.

My other friend stayed with me.

I showed my computer teacher Question 8 and asked whether my mark could be reconsidered.

Initially, she didn't change it.

Instead, she opened the textbook to check the topic.

She was looking through one chapter, but I remembered that the relevant topic was actually in another chapter. I pointed that out.

Eventually, she found the question in the textbook exercise.

And that's where the real discussion started.

The Debate

My teacher believed that Memory was the answer.

I explained why I believed Network was the correct answer.

My reasoning was simple:

A mobile phone depends on network connectivity for many communication-related functions. Lack of network connectivity can therefore be a limitation.

Meanwhile, I didn't understand how memory itself could be considered the answer to a question asking what is not a limitation.

We went back and forth for quite some time.

I wasn't trying to disrespect my teacher.

I simply couldn't make the explanation fit with what I understood from the textbook.

Eventually, after the discussion had gone on for quite a while, my teacher increased my mark.

So I got my 20/20.

I thought that was the end of it.

It wasn't.

My Friend Had the Same Answer

The next working day, my friend came to me.

He had also selected D. Network.

He told me that he should receive the mark too.

I agreed.

But I suggested something slightly different.

Instead of simply asking the teacher to give him the mark, I told him to ask:

"If this exact question appears in the annual examination, which option should we select?"

That question mattered.

Because getting one mark back was one thing.

Knowing the correct answer for the actual examination was much more important.

My friend asked the teacher about it.

The answer he got was still C. Memory.

And I couldn't understand it.

If the question appeared in our annual exam, I didn't want to knowingly select an answer I believed was technically incorrect.

Taking the Question to the Principal

It was examination time, so teachers were busy with invigilation and other responsibilities.

My friend's paper wasn't resolved immediately.

So I decided to ask someone else.

I went to the principal during dispersal.

I explained that I had a doubt regarding a previous computer science unit test.

At first, the principal was understandably annoyed because it was exam time and I was bringing up an old test.

But once I explained the actual issue, she said that it would be clarified.

I went home.

And instead of just thinking about the argument, I did something more useful.

I started looking for evidence.

I Went Back to the Textbook

I searched through the textbook again.

This time, I wasn't looking for something that would simply prove me right.

I was looking for the actual explanation of the concept.

And then I found it.

There was a line in the textbook that supported my interpretation of the question.

That was important.

Now I wasn't relying only on my memory or opinion.

I had a source.

The Next Day

When I came to class the next day, my class teacher asked me about the situation.

She knew that I had taken the question to the principal.

I explained what had happened.

Then she checked the question independently.

The answer she got was:

D. Network.

I also showed her the relevant line from the textbook.

At that point, there was evidence from the textbook supporting my answer as well.

The issue was finally clear.

The original answer I had been marked wrong for was actually the answer I should have received credit for.

What I Learned From One Mark

Looking back, the most important part of this story isn't that I got one additional mark.

It's what happened while trying to resolve the disagreement.

I learned that authority doesn't automatically make an answer correct.

A teacher can know far more about a subject than a student and still make an occasional mistake.

A textbook can contain an unclear question.

An answer key can be wrong.

And a student can misunderstand something.

That's why evidence matters.

Don't Argue Just to Prove Yourself Right

There's an important distinction here.

I'm not saying students should challenge teachers about everything.

And I'm definitely not saying that students should assume their teachers are wrong.

Instead:

If you believe something is technically incorrect, investigate it.

Don't just say:

"I'm right."

Ask:

"What does the textbook say?"

"What does the documentation say?"

"Can I find another reliable source?"

"Can I explain why I believe this answer is correct?"

That changes an argument into an investigation.

The Internet Makes This Even More Important

As someone who enjoys computer science and software development, I've started noticing this even more.

In technology, you can't always rely on someone's authority.

A person might confidently tell you that an API works one way.

The documentation might say otherwise.

Someone might tell you a programming concept is impossible.

You might test it and discover that it isn't.

Someone might tell you that a particular piece of code is correct.

Running it might prove otherwise.

That's why one of the most valuable skills for a developer is learning to verify information.

What Would You Have Done?

If you were in my situation, what would you have done?

Would you have:

Accepted the answer and moved on?

Asked the teacher again?

Checked the textbook?

Looked for another reliable source?

Asked another teacher?

Taken the issue to the principal?

For me, the biggest lesson wasn't getting 20/20.

It was learning that asking questions respectfully and finding evidence can be more powerful than simply arguing.

And sometimes, the answer really is worth investigating.

I’m a Student Developer. Is Building Projects Actually Better Than Following Tutorials?

Aditya Sorathiya — Mon, 14 Sep 2026 15:33:10 +0000

I've spent the last few months building and maintaining my own projects instead of constantly jumping between tutorials.

It has been frustrating sometimes. I've had bugs that took hours to understand, deployments that broke, features that I later had to rewrite, and projects that nobody used.

But I've also learned things that I don't think I would have learned by simply completing tutorials.

So I'm curious:

For someone learning development, what do you think is more valuable — building projects or following structured courses?

I Just Made PasteDB Pasts Editable Directly Inside VS Code 🚀

Aditya Sorathiya — Mon, 14 Sep 2026 05:07:02 +0000

I just released PasteDB VS Code Extension v0.3.0, and this update adds one of the features I wanted most: Update Paste. You can now open an existing PasteDB paste in a VS Code editor, edit it like normal code, and update it with Ctrl + Shift + U — without going back to the browser. In this post, I'll share how I redesigned the update workflow and why I chose an editor-first UX.

PasteDB VS Code Extension
PasteDB on GitHub
PasteDB

Making PasteDB Easier to Read: Word Wrap & Font Size Controls

Aditya Sorathiya — Fri, 11 Sep 2026 15:57:51 +0000

Hey everyone! 👋

I'm Aditya, a student developer, and I'm building PasteDB — a paste-sharing platform for code, text, notes, logs, and more.

While using PasteDB myself, I noticed a small but annoying problem.

If a paste contained a very long line, the viewer would require horizontal scrolling.

That isn't a huge problem for code, but for normal text, notes, documentation, or things like copied questions, it can make reading pretty uncomfortable.

So I decided to improve the viewer.

📝 Introducing Word Wrap

PasteDB's viewer now has a Word Wrap option.

When word wrap is disabled, long lines stay on a single line:

This is a very long line that continues and continues and requires horizontal scrolling...

When enabled, the same content can automatically wrap inside the viewer:

This is a very long line that continues
and continues and now wraps naturally
inside the available space.

The important part is that this is soft wrapping.

The actual paste content isn't modified.

So copying the paste still gives you the original content exactly as it was.

🔤 Font Size Control

I also added a font-size slider.

Instead of having only one fixed font size, you can adjust the viewer to whatever feels comfortable.

Something like:

Small  ────────●─────────  Large
                 16px

The selected size is applied to the paste viewer and the output area as well.

This is particularly useful when viewing PasteDB on different screen sizes.

⚙️ Why I put them inside "More Options"

Initially, I considered putting both controls directly in the toolbar.

But the PasteDB viewer already has several actions:

Copy
Raw
Images
Run
Nearby Share

Adding two more buttons would make the toolbar increasingly crowded, especially on mobile.

So I decided to keep the main actions visible and put the reading controls inside a More Options menu.

That keeps the interface cleaner while still making the settings easy to access.

💾 Your preference is remembered

I didn't want users to have to enable Word Wrap every time they opened a paste.

So PasteDB stores the preferences locally using localStorage.

For example:

localStorage.setItem(
  "pastedb_word_wrap",
  "true"
);

And the font size is stored similarly.

This means your viewer preferences can persist between paste views without requiring an account or changing the actual paste.

🛠️ A small technical challenge

Getting word wrapping to work properly wasn't just adding:

white-space: pre-wrap;

PasteDB's viewer uses <pre>
and <code> elements, and the <pre> originally had a min-width based on the content.

That meant a very long line could force the code block to become wider than the screen.

So the important part was allowing the code block to shrink to the available width:

pre {
    width: 100%;
    max-width: 100%;
    min-width: 0;
}

Then the code itself can wrap:

code {
    white-space: pre-wrap;
    overflow-wrap: anywhere;
}

Without fixing the width behavior, the "word wrap" setting doesn't really feel like word wrap.

🎯 Why these small features matter

This isn't a huge feature.

It's basically two viewer settings.

But I think these are the kinds of small improvements that make a product feel much better to use.

PasteDB isn't only used for code. You can paste:

📝 Notes
💻 Source code
📋 Logs
📄 Long text
📚 Documentation
🔗 Links
🖼️ Images
🔐 Private/encrypted content

So the viewer needs to work well for more than just programmers looking at code.

🚀 What's next for PasteDB?

I'm continuing to improve PasteDB and add features based on things I actually need while using it.

Some of the things I've already worked on include:

Syntax highlighting
Markdown preview
Custom URLs
Paste expiration
Password-protected pastes
Image pastes
QR sharing
Nearby transfer
Version history
API access
End-to-end encrypted pastes
A built-in code runner

And there are still a lot more ideas I want to experiment with.

💬 I'd love your feedback

If you use PasteDB, I'd love to know:

What would you improve about the viewer?

Is there a feature that would make reading or sharing pastes easier?

I'm especially interested in small UX improvements like this one.

Thanks for reading! ❤️

PasteDB: https://pastedb.netlify.app

GitHub: https://github.com/sorathiya903/pastedb

The cover image is AI generated
The real UI is like

The UI may change after time

I Found a “Case Study” About My Open-Source Project — But Its Development History Didn't Match Reality

Aditya Sorathiya — Wed, 09 Sep 2026 16:09:05 +0000

I recently discovered an article about PasteDB, an open-source project I built.

At first, I was actually happy to see someone writing about the project.

Then I started reading it.
I found that several parts of the article described PasteDB's technology, development process, and history in ways that don't match the actual project.

The article

The article is titled:

“Crafting a Product in Three Months: The Journey of Building PasteDB”

Read the article

Several important details don't match the actual project.

1. The technology stack is incorrect

The article claims that PasteDB uses:

Flask
React.js
PostgreSQL
Heroku

It even provides a Flask/PostgreSQL code example as part of the supposed PasteDB development process.

However, that isn't the technology stack of my actual PasteDB project.

The real repository is here:

https://github.com/sorathiya903/pastedb

The repository and its history provide the actual implementation and development record.

2. The article describes a development process that wasn't mine

The article describes things such as:

specific development sprints
a Flask REST API
PostgreSQL models
React components
unit and integration testing
deployment to Heroku

These are presented as the development journey of PasteDB.

But they don't represent how I actually built the project.

The article's footer identifies the website as being designed and developed by its operator:

This is what surprised me the most.

It's one thing to write an article about an open-source project.

It's another thing to present a development history as the project's actual history when that history does not match the project's repository and documented development.

3. What PasteDB actually is

PasteDB is a developer-focused paste-sharing platform that I've been building from my own repository.

The project has evolved considerably over time.

Some of the things I've built include:

End-to-end encryption
Public, private and unlisted pastes
Expiration and burn-after-read options
Markdown and syntax highlighting
Image sharing
QR sharing
Nearby transfer
Search and Explore
Version history
REST API
Python/Node tooling
CLI
VS Code extension
Code execution
Dashboard and analytics

PasteDB: https://pastedb.netlify.app

Github: https://github.com/sorathiya903/pastedb

4. I tried contacting the website

Before escalating the issue, I tried contacting the website using the email addresses available to me.

I found the following email addresses on the website's pages:

Unfortunately, the messages weren't delivered.

Attempt 1

me@ayubbaba.in

Result:

554 5.7.1 — Relay access denied

Attempt 2

legal@ayubbaba.in

Result:

554 5.7.1 — Relay access denied

I wasn't able to establish contact through those addresses.

5. The issue has now been resolved (14/9/26)

The website operator directly got back to me and acknowledged the attribution issue.I got the email from operator on 13/9/26 at 9 PM

They explained that they had been inactive for some time and apologized for the delayed response.

Most importantly, they confirmed that they had removed the article completely.

I checked the original URL myself:

https://ayubbaba.in/blog/crafting-a-product-in-three-months-the-journey-of-building-pastedb

The PasteDB article is no longer there. The URL now displays the operator's portfolio page instead.

So from my side, the issue has now been resolved.

I also informed Hostinger about the situation, but since the website operator has already removed the article, I don't expect any further action to be necessary.

Why I'm keeping this post

I'm not keeping this post up to attack the website operator.

The original article contained screenshots and information that documented what happened, and I think the situation provides an interesting lesson for other open-source developers.

Your repository isn't just your code. It's also a record of your work.

Commit history, releases, documentation, licenses and timestamps can help establish how a project actually evolved.

If you're building something publicly, keeping that history organized is valuable.

What I learned

Keep your repository history

Don't treat Git history as something disposable.

It can become an important record of how a project evolved.

Keep your documentation accurate

A clear README and changelog make it easier for others to understand what your project actually does.

Keep licenses visible

Open-source licenses explain what other people can and cannot do with your code.

Document everything

When you find an issue involving your work, keep records of what you found.

Screenshots, URLs, emails, error messages, repository history, and timestamps can help establish what happened and what steps you took to resolve it.

In my case, keeping the original article screenshots and documenting my attempts to contact the website helped me keep a clear record of the situation.

Verify claims before publishing them

A publicly available project can be researched and discussed, but technical details and development history should be verified before being presented as fact.

An update for anyone reading this later

The original article has been removed.

The website operator confirmed the removal directly to me, and I verified that the article is no longer available at its original URL.

I'm leaving this post as a record of the situation rather than as an ongoing complaint.

I'd like to hear from other developers

Have you ever found an article, video, tutorial, or website describing your open-source project incorrectly?

How did you handle it?

Did you contact the author first, report it to the platform, or simply leave it alone?

I'd be interested in hearing how other developers handle situations like this.

PasteDB: https://pastedb.netlify.app

GitHub: https://github.com/sorathiya903/pastedb

PasteDB development story: https://pastedb.netlify.app/about

I built a Neo-Brutalist website for MagicDrop — a local-network file sharing CLI

Aditya Sorathiya — Mon, 07 Sep 2026 16:24:08 +0000

I just launched a new website for MagicDrop, my local-network file and text sharing CLI.

I wanted the website to feel as unique as the project itself, so I redesigned it with a bold neo-brutalist UI — thick borders, hard shadows, high-contrast typography, and vibrant lime accents.

For now, the website has two pages:

🏠 Landing / Home page — introduces MagicDrop, features, installation, commands, browser sharing, local-network architecture, and the latest release.
📦 Releases page — a dedicated release history showing MagicDrop 0.0.2 and the first 0.0.1 release.
The site is built with plain HTML, CSS and JavaScript, with responsive navigation and small reveal/copy interactions.

MagicDrop: a simple way to share files and text between terminal and browser over the same local network, without cloud storage.

🔗 Website: https://magicdrop-cli.netlify.app
📦 NPM: https://www.npmjs.com/package/magicdrop-cli
💻 GitHub: https://github.com/sorathiya903/MagicDrop

Why only 2 pages for now?

I m a student,so now my tests are going one.
The other pages can be released after 20/9/26

I'd love to hear what you think about the design and what I could improve in future pages!

How I Added Server-Side File Size Limits to a WebSocket File Sharing App

Aditya Sorathiya — Fri, 04 Sep 2026 10:06:29 +0000

🚀 MagicDrop 0.0.2 is here!

I just added a configurable file-size limit to MagicDrop, my local-network file and text sharing tool for terminal and browser.

📦 Default limit: 512 MB

You can now set your own limit when starting MagicDrop:

md start --limit 1GB

Supported:
• KB
• MB
• GB

The limit is enforced on the server, with browser-side validation too.

I also improved the browser UI and fixed several file-transfer issues.

📦 NPM:
https://www.npmjs.com/package/magicdrop-cli

⭐ GitHub:
https://github.com/sorathiya903/magicdrop

Would love to hear your feedback! 🙌

A tool which can share files and text between your terminal and browser over your local network. No cloud storage or internet needed.

Aditya Sorathiya — Thu, 03 Sep 2026 01:19:24 +0000

Have you ever needed to quickly move a file or some text between your phone and computer without uploading it to a cloud service?

I built MagicDrop, a simple local-network file and text sharing tool that connects your terminal with a browser.

You start MagicDrop from the terminal, scan a QR code, and your browser becomes a connected device.
MagicDrop supports:

💻 Terminal → Browser file sharing
🌐 Browser → Terminal file sharing
🌐 Browser → Browser file sharing
💬 Text sharing between devices
📱 Multiple connected devices
📷 QR-code connection
✅ Transfer approval/rejection
📦 Chunk-based file transfers
📁 Automatic downloads on the terminal

The first version, v0.0.1, is now released.

Github: https://github.com/sorathiya903/MagicDrop

🚀 Install

npm install -g magicdrop-cli

Start it:

md start

MagicDrop starts a local server and displays a QR code. Scan it from another device connected to the same local network.

📁 Send a file

From the terminal:

md> send photo.jpg

The receiving device gets an approval request. Once accepted, the file is transferred in chunks.

💬 Send text

md> send-text Hello from MagicDrop!

No quotes are required.

🔢 Check version

md -v

Output:

MagicDrop 0.0.1 by Aditya Sorathiya

Version might be different as new version come.

This is my first release of MagicDrop, and I'm planning to keep improving it.
I'd love to hear what features you think would make MagicDrop more useful. 🚀