DEV Community: Somu Parida

When Should Screenshots Live in Git, and When Should They Be Hosted Elsewhere?

Somu Parida — Fri, 25 Sep 2026 13:54:25 +0000

A screenshot can turn a vague bug report into something you can act on. But once you capture it, where should it live: in the repository, attached to the issue, or at a separate URL? The right choice depends on whether the image is part of the project, evidence for one discussion, or an asset other people need to reuse.

Keep it in Git when it belongs to the project

Commit an image when it explains the product or documentation and should change alongside the code. That might be a screenshot showing the expected output of a documented command, or a diagram that a pull request updates with an architecture change. A stable path also makes the image easy to reference from a README or docs page.

Use a descriptive filename, add useful alt text, and export only the dimensions and quality the page needs. Large binaries can add weight to repository history even after you replace them. GitHub’s large-file guidance explains the file and repository size limits to keep in mind.

Attach it when it is evidence for one conversation

A screenshot of a one-off layout bug usually belongs with the issue or pull request where the fix is discussed. The image stays beside the reproduction steps and reviewer comments, but it does not become a permanent project asset after the conversation is resolved.

Check the visibility of the issue before sharing. An attachment that only teammates can open will not help a reader following a public tutorial. Redact access tokens, email addresses, customer data, and unrelated browser tabs before uploading; cropping or marking up the image itself is safer than relying on a note in the surrounding thread.

Host it separately when it needs to be reused

A hosted image makes sense when several repositories or a content system need the same asset, or when the destination accepts a URL but cannot store the file in your repository. This adds a dependency: the page now relies on another service keeping the image available to the intended readers.

For a Markdown image, the URL should return the image itself. For example:

![Menu overlapping at a narrow viewport](https://example.com/screenshots/menu-overlap.png)

A share or preview page may open perfectly in a browser tab but still fail inside an image embed, because the embed expects image data rather than a webpage. Use a share page when someone should open a normal page to inspect the file; use the direct media URL when the document needs to render the image inline.

Disclosure: Media2URL is my project. Its Image to Link tool returns a direct media URL for embeds and a separate share page for browser viewing. It is one possible way to host a local screenshot; whichever service you use, check its access and expiry settings before you make the link part of documentation.

A quick decision check

Will the image change with the code or docs? Keep it in the repository.
Is it evidence for one bug report or review? Attach it to that discussion.
Does it need the same address in several public places? A separate host may fit.
Can a reader open the image without your account, and will it stay available as long as the page needs it?

My default is to commit stable project documentation, attach temporary evidence to its discussion, and host reusable public assets only when the URL’s lifetime and access rules are clear. Keep the original file somewhere you control, then open the final URL in a private browser window before you rely on it.

How I Built TextToPDF.net: A Minimalist Tool for Clean Document Conversion and OCR

Somu Parida — Mon, 06 Apr 2026 19:10:28 +0000

If you’ve ever tried to convert a simple text file to a PDF or extract text from a grainy scan, you’ve probably dealt with bloated "all-in-one" PDF suites. Most of them are filled with ads, require account sign-ups, or have confusing interfaces.

That’s why I built TextToPDF.net—a focused document tool designed for speed, clarity, and a distraction-free workflow.

The Problem
Traditional PDF tools often overcomplicate simple tasks. If you just need a clean PDF from a text draft or need to pull text out of a document to edit it, you shouldn't have to navigate a heavy UI.

What TextToPDF.net Does
I built this tool to follow a "do one task properly" philosophy. Here’s what it handles:

Text to PDF: Paste text or upload files to get a structured, readable PDF instantly.

PDF to Text: High-speed extraction to make your documents editable again.

AI-Powered OCR: Converts scanned images and non-selectable PDFs into readable text using advanced character recognition.

Privacy-First: We use temporary file processing. Your data isn't stored long-term, which is a major friction point with other online converters.

The Workflow
The tool follows a simple 3-step process:

Upload/Paste your content.

Process (Formatting or OCR).

Download your result.

Why I’m Sharing This
I wanted to create something for students, writers, and developers who value their time. Whether you're converting logs, notes, or old scans, it should be a 10-second task, not a 10-minute one.

I’d love for the DEV community to check it out and let me know what you think!

👉 Try it here: TextToPDF.net

Launch: Free Gift Card API to Convert Points into ₹INR + Trends (No Auth Needed)

Somu Parida — Wed, 14 May 2025 09:57:32 +0000

✨ Launching: Free Gift Card Estimation & Trends API (No Auth Needed)

We're excited to launch a simple and fast API that lets you convert reward points into estimated INR value and view trending gift card types — all with just a POST request.

This is perfect for developers building reward apps, survey platforms, gamified systems, or personal finance dashboards.

🔧 What Does This API Do?

🟢 Estimates the INR value of gift cards based on collected points
📈 Returns trending gift card types with popularity scores
⚡ Fully deployed on Vercel for fast global performance
🛡️ No authentication required
🔄 Returns a clean JSON response ready to use in your frontend or backend

🧪 Sample API Usage

Endpoint:

POST https://gift-card-xxxxx.vercel.app/api

Example Request Body:

{
  "action": "estimate",
  "type": "Amazon",
  "points": 1500
}

Example Response:

{
  "estimated_value": "₹150"
}

📊 Trends Mode

Want to see which gift cards are trending?

Request:

{
  "action": "trends"
}

Response:

{
  "trends": [
    { "type": "Amazon", "popularity_score": 95 },
    { "type": "Flipkart", "popularity_score": 85 }
  ]
}

🔗 Live Links

🌍 Live API: [https://gift-card-6h130hufo-sagarsonu24s-projects.vercel.app/api)

* 🔗 Official Website: https://www.FreeGiftZone.com

💡 Who Is It For?

This is made for:

Reward-based app creators
Game and quiz platforms
Task completion platforms (survey, watch & earn, etc.)
Developers needing INR-based point conversions
Anyone building gamification around gift cards

🚀 Why We Built This

This API is part of our platform at FreeGiftZone.com, where users earn points by watching ads, completing surveys, playing games, and redeeming them for gift cards. We needed a way to convert these points into ₹INR in real-time for the app and web interface.

So we built this API and made it public — for anyone to use without auth or payment.

🙌 Let’s Collaborate

If you're building something similar or want to use this API in your own platform, feel free to integrate it. You can even fork the repo or request a feature.

Leave your thoughts, feedback, or use-cases in the comments — we'd love to see what you’re building with it.

💬 Made with 💙 in India by the team at FreeGiftZone.com
📩 Contact: sourav@freegiftzone.com
🏷️ Tags: #api #giftcards #rewards #nodejs #vercel #openapi #developers #india