How to Check If Software Is Safe Before You Download or Install It

The short answer

You cannot prove that unfamiliar software is completely safe from one badge, review, scan, or store listing. You can make a much better decision by checking several independent questions before you download, install, connect an account, or enter payment information.

Start by confirming that you found the real publisher and official download location. Then review what the software does, what access it requests, how it handles data, how it is maintained, and whether its public claims match the available evidence. The goal is not perfect certainty. It is to avoid trusting the wrong product, the wrong website, or the wrong installer.

This checklist works for desktop programs, mobile apps, browser extensions, command-line tools, and online software. The exact technical checks differ, but the trust questions are remarkably consistent.

1. Find the official software source

Search results, advertisements, social posts, download directories, and copied links can all lead to a page that looks official. Do not begin with the download button. Begin with the identity behind it.

Compare the product name, publisher name, official domain, store publisher, support address, and company information. If several pages claim to be official, independently find the publisher through a known profile, established documentation, verified store listing, or another source that the download page does not control.

Use the main CheckLink scanner to inspect the public product or download-page URL before opening it. If the address is shortened or tracked, use the Redirect Checker to reveal the destination. If the domain resembles a familiar brand but is not exact, compare it with the expected domain in the Lookalike Domain Checker.

HTTPS is useful, but it only shows that the connection to that domain is encrypted. It does not prove that the domain belongs to the publisher you intended to reach.

2. Check whether the publisher identity is consistent

A trustworthy product should make it reasonably possible to answer who operates it. Look for consistent names across the website, privacy policy, terms, store listing, documentation, support channels, and software signature.

Normal differences can exist. A product name may differ from its legal company name, and a developer may use an approved distribution provider. The important question is whether those differences are explained and connected rather than hidden.

Pause when the website names one company, the installer names another unrelated publisher, support uses an unexplained free mailbox, or the privacy policy belongs to a different service. One mismatch is not proof of abuse, but it needs a credible explanation before the product receives access to a device or account.

3. Understand exactly what you are installing

Write down the product's claimed job in one sentence. Then compare that job with the access it requests.

A screenshot tool may need screen-capture access. A password manager may need to read and fill website fields. A video-call product may need the camera and microphone. Those permissions can be reasonable when they are necessary, clearly described, and controllable.

The same permission deserves more caution when it has no obvious relationship to the product. A simple calculator should not need access to contacts, messages, accessibility services, or every website you visit. A browser extension that changes one page should explain why it requests broad access across all sites.

Do not approve permissions only because the operating system or browser displays a standard dialog. The dialog confirms what the software is requesting, not whether the request is appropriate.

4. Review privacy and account access before connecting

Software risk is not limited to malware. A legitimate product can still collect more information than expected, retain it too long, share it broadly, or request account access that is disproportionate to its purpose.

Before connecting Google, Microsoft, Amazon, GitHub, a bank, an advertising platform, or another business account, review the exact authorization scope. Read-only access is different from permission to create, edit, delete, send, or manage users. Access to one workspace is different from access to every workspace in an organization.

Look for clear answers to these questions:

• What data is collected?
• Is the data stored, and for how long?
• Is it used to train models or improve unrelated products?
• Is it shared with service providers or advertisers?
• Can the user disconnect the account and delete stored data?
• Does the product explain security and incident-contact routes?

If these answers are missing, treat that as unresolved uncertainty rather than inventing a reassuring assumption.

5. Check the download and installer itself

When software must be downloaded, use the publisher's official site, an official operating-system store, or a repository linked by the publisher. Avoid repackaged installers, mirrors, cracks, activation tools, and pages that ask you to disable security protections.

Where the publisher provides a checksum, compare it with the downloaded file before execution. A matching checksum can show that the file matches the publisher's published copy. It does not prove that the publisher or the software is trustworthy, so it remains one part of the review.

On supported platforms, inspect the digital signature and publisher name. Stop if the signature is invalid, unexpected, or missing where the publisher says it should exist. Use the operating system's current security protections and do not bypass a warning merely because a download page tells you to do so.

CheckLink reviews public URLs and trust context. It does not download, execute, reverse engineer, or certify an installer package. File analysis and isolated testing require separate security controls.

6. Read reviews as evidence, not a vote

A high rating is not the same as an independent security review. Reviews may describe usability, pricing, support, or a previous version rather than the current product's security and privacy.

Look for specific, recent patterns. Do users report unexplained permission changes, unwanted browser behavior, difficult cancellation, unexpected charges, missing exports, inaccessible support, or account-access concerns? Also check whether the publisher responds with concrete explanations and documented fixes.

Do not reject a new product only because it has few reviews. New software naturally has less public history. Instead, reduce the initial exposure: use a test account, avoid sensitive data, limit permissions, and verify the publisher more carefully.

7. Check maintenance, changes, and support

Software changes after installation. Ownership can change, permissions can expand, dependencies can be compromised, and a previously useful product can become abandoned.

Look for a visible update history, current documentation, supported platform versions, a working support path, and a way to report security problems. For open-source software, repository activity and transparent releases can add context, but a public repository alone does not prove that the distributed package matches the source or that every change has been reviewed.

Recheck important software when it requests new permissions, changes ownership, moves to a different domain, introduces a new installer, or asks users to reconnect an account.

Browser extensions need a focused permission check

Browser extensions operate close to browsing activity and can request access to pages, tabs, downloads, storage, or authentication flows. Confirm that you are on the official store listing and that the publisher and linked website agree.

Read the permission explanation before installation. Ask whether the extension needs access on every website or only when the user activates it. Review its privacy disclosure, update history, support route, and the controls for disabling or removing it.

For comparison, the official CheckLink browser extension page describes availability, permissions, privacy boundaries, and the centralized Chrome Web Store destination before installation.

SaaS products still require a pre-use check

Online software may not place an installer on the device, but it can receive business data, account tokens, payment details, customer records, or administrative access. Check the sign-up domain, company identity, authorization scopes, export options, deletion path, billing terms, and support route.

Start with the least sensitive data and lowest practical permission level. A product that can be tested without connecting a production account should not begin with unrestricted production access.

A five-minute software safety checklist

1. Confirm the exact official domain, publisher, and store or repository listing.
2. Inspect the destination URL and redirects before opening an unfamiliar download page.
3. Compare the product's purpose with every requested permission.
4. Read the privacy terms and account-authorization scope.
5. Use the official download source and keep platform security protections enabled.
6. Verify signatures or checksums when the publisher provides them.
7. Look for recent, specific review patterns and a working support route.
8. Check maintenance history, ownership changes, and recent permission changes.
9. Start with limited data, a test account, or reduced access when uncertainty remains.
10. Reassess after major updates instead of treating one past check as permanent.

What a CheckLink trust page adds

The CheckLink Launch Board gives software a public place for reviewed identity, ownership, official links, capabilities, availability, limitations, and trust context. That can make important questions easier to find before leaving CheckLink.

A listing is not a guarantee that software is secure, risk-free, suitable for every user, or unchanged forever. It is structured context that should be combined with platform protections, permission review, current documentation, and the user's own risk level.

Software owners who want a public listing and trust page can submit their software to CheckLink. Before submitting, the Website Trust Checklist can help identify missing official links, policies, support information, and launch details.

Make the decision proportional to the risk

Installing a simple tool on a test device is different from granting an unknown product access to company email, customer data, advertising accounts, source code, or financial systems. The more sensitive the access, the more independent evidence and internal approval the decision should require.

If the source, publisher, permissions, privacy terms, and requested access all make sense, you have a stronger basis for proceeding carefully. If several important questions remain unanswered, the safest next step is to pause, contact the publisher through an independently found channel, or choose a product with clearer evidence.