DEV Community: Widodo Purnomosidi

Building CipherBite: An Offline Text Encryption App to Share Credentials Securely

Widodo Purnomosidi — Fri, 31 Jul 2026 03:37:12 +0000

Sharing sensitive credentials—like passwords, PINs, or API keys—via chat or email is a common habit, but it comes with a massive privacy risk if a device is lost or compromised. As developers, we constantly share environment variables and access tokens over Slack or WhatsApp out of convenience, often ignoring the security implications.

If you have ever wondered how to send passwords securely on WhatsApp without relying on a bulky password manager, you are not alone. CipherBite is designed to solve this exact problem.

Instead of sending plain text, CipherBite converts your sensitive information into unique, encrypted cipher text that can only be decoded through the app. I built this offline text encryption app to serve as the perfect middle ground between the convenience of quick messaging and the high-level security of dedicated tools.

Here is a deep dive into how I built it, the tech stack I chose, and the security architecture behind it.

🛠️ The Tech Stack
To build a high-performance, natively compiled application from a single codebase, I chose Flutter. For a security-focused app, maintaining a single codebase minimizes the surface area for bugs and vulnerabilities.

For state management, Riverpod is the backbone of CipherBite. It is compile-safe and seamlessly separates the UI from the heavy AES-256 encryption logic, ensuring the app reacts instantly to database changes—like restoring a vault from a backup—without requiring the user to restart the app.

🔒 Security First: "Never Roll Your Own Crypto"
When building an app to hide secret text in chat, I had to strictly adhere to the golden rule of cybersecurity: "Never roll your own crypto". Custom encryption algorithms are easily reverse-engineered.

That is why CipherBite is powered by industry-standard AES-256 encryption, ensuring your data is scrambled into completely secure, unreadable text. Furthermore, the app operates 100% offline, relying entirely on on-device computation without the need for a backend server. This means zero data collection and maximum privacy.

Users can also encrypt text message with PIN protection, adding an extra layer of security that requires a specific PIN to decode a secret message.

🗄️ Double-Layer Security with SQLCipher
Local storage is critical for a strictly offline, privacy-first application. To store the user's encryption history locally, I chose SQLite—specifically the SQLCipher implementation.

This creates a double-layer security architecture:

Text Level: The raw text is scrambled using AES-256.
Storage Level: The .db file saving that AES text is fully encrypted by SQLCipher.

Even if a device is rooted or compromised, the local vault ensures zero data leaks.

☁️ Secure Cloud Backups with Google Drive API
While the app is completely offline, users still need a way to back up their local vault. I integrated the Google Drive API to provide a seamless cloud backup solution.

I chose it specifically because of its unique appDataFolder scope. This scope creates a hidden, protected folder in the user's personal Google Drive. This ensures users have full control over their encrypted backups without the risk of accidentally tampering with or deleting the vault from their regular Drive interface.

🚀 Wrapping Up
Building CipherBite was an incredible journey in balancing frictionless UX with military-grade security. It acts as a lightweight, privacy-focused alternative to generic encryptors by focusing purely on securing standard messaging apps.

If you are interested in trying it out, CipherBite is now available on the Google Play Store!

I would love to hear your thoughts, feedback, or any questions about implementing SQLCipher and Google Drive API in Flutter.

Drop a comment below! 👇

Why Your QR Code Can Expire — And How to Make a Permanent One

Widodo Purnomosidi — Sun, 19 Jul 2026 15:59:37 +0000

Why Your QR Code Can Expire — And How to Make a Permanent One

Here's a scenario that's more common than you'd think: you design a beautiful flyer, business card, or product label. You slap a QR code on it, print a few hundred copies, and move on with your life.

Six months later, someone scans it... and gets a "page not found." Or worse, it redirects to some random ad site that has nothing to do with you.

You didn't touch the printed material. You didn't change your website. So what happened?

The QR code itself "expired." And once you understand why, you'll never generate one the same way again.

The Sneaky Secret Behind Most "Free" QR Generators

Here's the thing nobody tells you upfront: a huge number of "free" QR code generators don't actually encode your link into the QR image. Instead, they generate a short redirect URL that lives on their servers — something like qr-provider.io/x7k2p — and that's what gets baked into your QR code.

When someone scans it, their phone hits that provider's server first, which then looks up where you actually wanted to send people, and redirects them there.

Why would a "free" tool do this? Mostly for analytics — scan counts, location data, device stats. Sometimes it's a straight-up upsell tactic: track for free, but pay to keep the redirect alive past a trial period.

It sounds harmless. It isn't.

Why This Comes Back to Bite You

Once your QR code depends on someone else's redirect server, your printed materials are only as reliable as that company's business decisions. A few ways this goes wrong:

The service shuts down or gets acquired. Redirect gone. Every QR code you ever printed with them is now a dead end.
You forget to renew, or hit a free-tier limit. Some providers quietly pause dynamic codes until you upgrade.
The shortener domain gets repurposed or sold. In the worst case, your old QR code could end up pointing somewhere you'd never want it to.
You literally cannot fix it after printing. Unlike a website, you can't push an update to ink on paper. If the redirect breaks, every flyer, sticker, and business card with that code is trash.

That last one is the real gut-punch. A broken link on a webpage is a five-minute fix. A broken QR code on 5,000 printed labels is a very expensive mistake.

Static QR Codes vs. Dynamic QR Codes

A QR code, at its core, is just a clever way to store a chunk of data as a scannable pattern of black-and-white squares. That's it. There's no inherent "expiration" built into the format.

The difference comes down to what data actually gets stored:

	Static / Direct QR	Dynamic / Tracking QR
What's encoded	Your actual content (URL, Wi-Fi password, contact info, etc.)	A short link pointing to the provider's redirect service
Needs a server to work?	No — works forever, even offline	Yes — depends on their infrastructure staying up
Can it "expire"?	No	Yes, if the provider stops the redirect
Analytics	None (by design)	Usually yes
Who controls it	You	The provider

Static QR codes are boring in the best possible way — they just work, indefinitely, because there's nothing external to fail.

How to Check If Your Current QR Code Is at Risk

Grab your phone and scan any QR code you've already printed. Look at the URL it opens.

If that URL is on a domain you don't own, and it looks like a shortener (random characters, a generic domain name that isn't yours or your destination's), you're looking at a dynamic code. It's working today, but its lifespan isn't really in your hands.

Making a QR Code That Actually Lasts

If you're about to print something — packaging, signage, a menu, a conference badge — this is worth doing right the first time:

Pick a generator that encodes data directly, with no middleman redirect. The content should be visible right there in the QR's raw data, not hidden behind a tracking link.
Match the QR type to your actual use case. A plain URL works for a website, but formats like vCard (contact info), Wi-Fi credentials, calendar events, or crypto wallet addresses can be encoded directly too — no app or server needed on the other end.
Test before you print. Scan it with two or three different phones and apps. Don't trust a single preview.
Use a higher error-correction level if the code will be handled, folded, or exposed to wear (think: product packaging vs. a clean digital banner).
Keep the destination itself stable. Even with a static code, if you're encoding a URL, make sure that page isn't going anywhere either.

I've been using Ic2Share's QR Code Generator for this exact reason. It runs entirely in your browser (nothing gets uploaded to a server), and it writes your content directly into the QR code — no redirect layer, no expiration, no account needed. It also supports things like vCards, Wi-Fi networks, geolocation, and crypto wallet addresses out of the box, which covers most of the "I need a permanent QR for X" situations you'll run into as a developer or small business owner.

The Bigger Point

A QR code is supposed to be a bridge — simple, dumb, reliable. The moment you route it through someone else's server for the sake of analytics, you've traded reliability for a dashboard you'll probably check twice and forget about.

If it's going on anything physical, permanent, or public-facing, encode it directly. Your future self — the one fielding "hey, this code doesn't work" messages — will thank you.

Have you ever gotten burned by a QR code that stopped working? I'd love to hear the story in the comments.

Stop Uploading Images to Random Servers: I Built a 100% Client-Side Image Processor

Widodo Purnomosidi — Fri, 17 Jul 2026 09:41:22 +0000

Have you ever needed to quickly crop, resize, or convert an image, only to find yourself on a random online tool that forces you to upload your sensitive files to their cloud server?

As a developer, this always bugged me. Not only is it a massive privacy risk (especially when handling personal documents or confidential project assets), but it’s also incredibly inefficient. Why round-trip a 5MB image to a server when modern browsers have all the APIs needed to process it locally?

That’s why I built the Image Crop, Resize & Convert Tool on Ic2Share.

It is a 100% client-side, offline-first image processor. Zero server uploads. Zero backend processing. Maximum privacy.

🏗️ The Architecture: Why Client-Side?
When designing the architecture for my web tools directory, my primary goals were:

Absolute Privacy: User data should never leave their device.

Low Operational Cost: By eliminating backend processing, I don't have to pay for expensive compute instances or bandwidth for file uploads/downloads. The entire site can be hosted statically.

Blazing Speed: Processing happens instantly via the user's own CPU/RAM.

To achieve this, I ditched traditional backend image libraries like ImageMagick or PHP GD, and relied entirely on Vanilla JavaScript and the HTML5 Canvas API.

✨ Features of the Tool
Free-form & Aspect Ratio Cropping: Easily crop images for social media headers or profile pictures.

Scale & Resize: Reduce massive camera photos down to web-friendly dimensions.

Format Conversion: Convert between JPEG, PNG, and next-gen formats like WebP.

Quality Compression: Adjust the compression slider to reduce file size without relying on a server-side compression engine.

🚀 Try It Out
You can test the tool right here: https://ic2share.com/image-processor.

Turn off your Wi-Fi after loading the page, and you'll see that it still works perfectly! This is the power of building offline-first web applications.

I’d love to hear your thoughts! What other client-side tools do you usually rely on for your daily workflow? Let me know in the comments below! 👇

I got tired of uploading private files to random servers, so I built a 100% client-side tool suite 🛠️

Widodo Purnomosidi — Thu, 16 Jul 2026 06:32:21 +0000

Hi DEV community! 👋 I'm Widodo, an independent web and mobile app developer.

In my day-to-day workflow—whether I am developing mobile apps, structuring databases, or setting up serverless continuous integration pipelines—I constantly rely on quick online utilities. Things like formatting code, generating QR codes, or stripping metadata from images.

But I realized a massive flaw in the current ecosystem of free online tools: Privacy and Performance.

If you search for a "Free EXIF Data Remover" or "JSON Formatter," 90% of the top results force you to upload your sensitive files to their remote servers just to perform a basic operation. Not only is this a massive privacy risk, but it also introduces unnecessary latency.

Since my core development philosophy has always leaned towards offline-first architectures and minimal server dependencies, I decided to build my own solution.

Enter Ic2Share.com.

It is a growing directory of web utilities built on a strict zero-server-upload architecture. Everything executes instantly within the user's browser.

Here is a breakdown of how I built some of the tools and the client-side APIs powering them.

Secure EXIF & Metadata Stripper (Canvas API) Most EXIF strippers use backend libraries (like PHP's exif_read_data or Python's Pillow). I wanted this to happen entirely offline so users wouldn't have to upload their personal photos.

The solution? HTML5 Canvas Re-rendering.
When a user drops an image, the browser reads it via the FileReader API. I then draw that image onto a hidden element. When you export the canvas back to a Blob using canvas.toBlob(), the browser automatically discards all original EXIF headers (including the exact GPS coordinates and camera models).

It is fast, secure, and costs $0 in server compute.

The Online Teleprompter (requestAnimationFrame)
I built an auto-scrolling teleprompter for video creators. Initially, I thought about using CSS transitions or setInterval for the scrolling text. However, CSS can cause jittering on large blocks of text, and setInterval drops frames.
SRT/VTT Subtitle Time Shifter (Regex Engine)
Have you ever downloaded a movie subtitle that is delayed by 2 seconds? I built a tool to fix that. Instead of uploading the .srt file, the user pastes the text, enters the millisecond offset, and Vanilla JS handles the rest using Regular Expressions.

It parses the HH:MM:SS,mmm format, converts it to total milliseconds, applies the shift (forward or backward), calculates the time rollovers, and spits out the synced text instantly.

The Architecture & Infrastructure
To keep operational costs practically non-existent while ensuring high speed, the entire suite is served statically. I utilize Cloudflare Workers to handle traffic routing and programmatic SEO setups, ensuring the application stays lightweight and highly available globally.

Other tools currently live on the site include:

Direct QR Code Generator (Bypasses URL masking)

Live Markdown Editor (With secure syntax highlighting)

Invisible Character & Blank Space Generator

and more..

I would love your feedback!
Building this has been a fun exercise in maximizing browser capabilities.

If you have a minute, check out https://ic2share.com.
I would love to hear your thoughts on the UI/UX. Also, as fellow developers, what specific client-side tool do you often wish existed (or was faster) that I can build next?

Let me know in the comments! 👇