DEV Community: Wendy

Free AI code review tools for open source projects (2026)

Wendy — Fri, 13 Nov 2026 09:03:59 +0000

Open source maintainers review pull requests from people they’ve never met, often in their spare time, and a busy project can get more contributions in a week than one maintainer can read. Several free AI code review tools now cover public repositories. They differ in whether you apply, what they limit, and whether you run anything yourself. Terms below are as of November 2026.

Free AI code review tools for open source, compared

Six free options cover public repositories, from install-and-go to self-hosted. The biggest differences are whether you apply and how many reviews a project gets.

The six free options one by one

The first two work as soon as they’re installed; the next three need an application or an invitation; the last runs on your own infrastructure.

1. HeyDeer

HeyDeer reviews public repositories free up to a fair-use limit, with no application, and popular public repositories can run more reviews at once than the Free plan includes. Each review reads the change against the whole repository, checks every finding before posting it, and follows the project’s REVIEW.md and AGENTS.md. HeyDeer has the highest precision in ReviewBench’s default view (a Deep review), so maintainers spend their time on comments worth acting on.

Best for: projects of any size that want reviews on every pull request, including contributors’ forks, without an application.

2. CodeRabbit

CodeRabbit gives public repositories its Team features free, with no credit card. Pull request reviews are rate-limited to between 1 and 10 per developer per hour depending on the repository’s stars, and repositories under 10 stars trigger reviews manually. It also reviews on GitLab, Bitbucket and Azure DevOps.

Best for: established projects outside GitHub, or teams that want the same reviewer in the IDE.

3. Greptile

Greptile reviews public GitHub and GitLab repositories with an OSI-approved license free once the project applies; projects with 50 or more stars are approved automatically. Its pricing page describes the program as for qualified non-commercial projects.

Best for: non-commercial projects with 50+ stars and large codebases.

4. Qodo

Qualified open source projects can apply to Qodo for Open Source for free access, then install Qodo’s GitHub app on the repositories they choose. Qodo reviews on GitHub, GitLab, Bitbucket and Azure DevOps, with Gerrit on Enterprise.

Best for: projects that mirror their code across several Git hosts.

5. GitHub Copilot

GitHub gives Copilot Pro free to maintainers of popular open source repositories and reevaluates eligibility every month. Copilot Pro includes pull request reviews on GitHub, paid from its monthly AI Credits, along with Copilot’s coding features.

Best for: maintainers who already qualify and want review inside GitHub’s own interface. GitHub Copilot code review

6. PR-Agent

PR-Agent is an MIT-licensed reviewer you run yourself as a GitHub Action, CLI, Docker container or webhook service, with your own key for OpenAI, Anthropic, Google, DeepSeek, Mistral or a local model. It’s community-maintained and separate from Qodo’s hosted product.

Best for: projects that need to choose the model or keep code on their own servers.

Hosted vs self-hosted: what free costs you

A hosted reviewer pays for the model itself; a self-hosted one is free software that runs on your model bill. For an open source project, the bigger difference is who can trigger a review.

GitHub’s documentation states that a workflow triggered from a forked repository receives GITHUB_TOKEN as its only secret. A self-hosted AI reviewer running as a GitHub Action therefore loses its model API key on contributors’ fork pull requests, where outside contributions arrive.

The usual workaround, the pull_request_target trigger, runs with the base repository’s secrets, and GitHub warns about its security risks when a workflow builds or runs code from the pull request. A hosted GitHub App such as HeyDeer or CodeRabbit sidesteps both: it reads the pull request through its own installation and calls the model with its own credentials, so fork pull requests get the same review as maintainers’ branches.

Which free option fits your project

A new or small project: HeyDeer reviews from the first pull request, whatever the star count.
A popular project with many outside contributors: a hosted GitHub App (HeyDeer or CodeRabbit) with fork pull requests included; check whether your maintainers also qualify for free Copilot Pro.
A non-commercial project with 50+ stars: Greptile’s program approves it automatically.
Code that has to stay on your servers: PR-Agent with a model you host, reviewing maintainers’ branches.

Code review prompts for Claude Code, Codex and ChatGPT

Wendy — Fri, 13 Nov 2026 08:33:52 +0000

A code review prompt is a reusable instruction that asks an AI model to review a diff. The prompts that work set the scope to the changed lines, ask for a severity, a file and line and the evidence for each finding, tell the model to skip style a linter catches, and give it a plain “No findings” answer for a clean change.

A general-purpose code review prompt

Start with this one. It works on any diff, in any tool, and the variants below reuse its output format so findings from different passes read the same way.

Review the code change below before it merges.

Report only problems this change introduces or makes worse:
bugs, security holes, data loss, crashes, broken error handling, and clear performance regressions.

Scope
- Review the diff. Read surrounding code only to confirm a finding.
- Skip formatting, naming and style that a linter or formatter catches.
- Skip problems that existed before this change, unless it makes them worse.

For each finding, give
- Severity: Critical, High, Medium or Low
- Location: file path and line number
- Problem: what goes wrong, and the input or sequence that triggers it
- Evidence: the lines of code that show it
- Fix: the smallest change that resolves it

Rules
- Report a finding only if you can point to the code that causes it.
  If you would need to check something first, say what, or leave it out.
- Order findings from most to least severe.
- If nothing meets this bar, reply with exactly "No findings."
  Don't add minor comments to fill the review.

<diff>
PASTE THE DIFF HERE
</diff>

The diff sits inside tags so the model can tell instructions from code, which matters when the diff itself contains comments or strings that read like instructions.

Code review prompts for focused passes

A single prompt that asks for everything tends to spread its attention thin. For changes that touch authentication, data access or a busy endpoint, run a focused pass as well. Each prompt below goes above the same block.

Security review prompt

Do a security review of the diff below. Look only for
vulnerabilities this change introduces:

- Input from users, files or the network reaching SQL, shell commands, file paths, HTML or templates without validation or escaping
- New endpoints, jobs or queries that skip authentication or authorization, or that return another user's or tenant's data
- Secrets, tokens or personal data written to code, logs or error messages
- Hand-rolled cryptography, weak randomness for tokens, disabled certificate checks
- New dependencies, and what they are given access to

For each finding: severity, file and line, how an attacker would reach it, and the fix. Rate severity by what an attacker could actually do, not by the category name. If you find nothing exploitable, reply "No findings."

Performance review prompt

Review the diff below for performance problems only.

Flag:
- Queries or network calls inside loops (N+1)
- Work that grows with input size where it didn't before: nested loops over collections, repeated scans, unbounded lists loaded into memory
- Missing pagination or limits on queries that can return many rows
- Expensive work added to a hot path: per request, per render, per message
- Caches that never expire, or that are keyed so they never hit

For each finding: file and line, the input size or traffic at which it starts to hurt, and a cheaper approach. Don't flag micro-optimizations the runtime or compiler already handles. If nothing qualifies, reply "No findings."

Test coverage prompt

Review the tests in the diff below against the code it changes.

1. List each behavior the change adds or modifies.
2. For each one, name the test that covers it, or say "not covered".
3. Point out tests that would still pass if the code were wrong:
   assertions on mocks only, snapshots nobody reads, missing
   assertions, or tests that never reach the changed branch.
4. List the edge cases worth a test: empty input, limits, errors from dependencies, concurrent calls, time zones.

Write test names and one-line descriptions, not full test code.
If coverage is adequate, say so in one sentence.

Pull request prompt: review only the diff

For a pull request, give the model the author’s stated intent as well as the diff. A review that compares the two catches changes the description never mentions, which is where unintended edits hide.

You are reviewing pull request #<NUMBER>: "<TITLE>".
The author says it does this: <ONE-LINE SUMMARY FROM THE PR DESCRIPTION>

Review only the lines this pull request changes, shown below as a diff against the base branch. Use unchanged code for context, but don't report issues in it.

First, in one or two sentences: does the diff do what the description says? Point out anything it does that the description doesn't mention.

Then list findings with severity (Critical, High, Medium, Low), file and line, the problem, and a suggested fix. Only report problems you can tie to a changed line. If there are none, reply "No findings."

<diff>
PASTE THE OUTPUT OF: git diff main...HEAD
</diff>

Prompt for reviewing AI-agent-written code

Code from a coding agent fails in its own ways: it calls functions that don’t exist, adjusts tests until they pass and quietly catches errors. This prompt points the review at those patterns. The code review checklist has the same questions for a human reviewer.

The diff below was written by a coding agent. Review it as you would a new teammate's first pull request, and look in particular for:

- Code that assumes an API, function, option or config key exists: check that each one it calls is defined in this repository or in a dependency at the installed version
- Tests changed to match the new behavior instead of the requirement: weakened assertions, deleted cases, new skips
- Errors swallowed so the code "works": empty catch blocks, broad fallbacks, default values that hide failures
- Duplicates of helpers that already exist elsewhere in the repository
- Changes outside the task: unrelated files, reformatting, renamed public functions
- TODOs, placeholders or hard-coded values left in place of real logic

For each finding: severity, file and line, evidence, fix. If the change is sound, reply "No findings."

How to run a Claude code review prompt as a slash command

In Claude Code, a prompt you reuse becomes a slash command. Save it as .claude/commands/review-diff.md and /review-diff runs it. Claude Code has merged custom commands into skills: a skill at .claude/skills/review-diff/SKILL.md creates the same command, and adds a folder for supporting files and the option for Claude to load it on its own when a task matches its description. Existing files in .claude/commands/ keep working.

---
description: "Review this branch against main for bugs and security issues"
argument-hint: [extra focus, optional]
allowed-tools: Bash(git diff *)
---

## Changed files
!`git diff --stat main...HEAD`

## Diff
!`git diff main...HEAD`

## Instructions
Review the diff above. Report only problems this change introduces: bugs, security holes, data loss, crashes, performance regressions.
Skip anything a linter or formatter would catch.

For each finding: severity (Critical, High, Medium, Low), file and line, the problem, the evidence, and the smallest fix.
If nothing qualifies, reply "No findings."

Extra focus for this review: $ARGUMENTS

!git diff main...HEAD runs before the prompt is sent, and Claude receives the command’s output in its place. Claude Code checks each injected command against your permission rules, so allowed-tools: Bash(git diff *) pre-approves it.

$ARGUMENTS receives whatever you type after the command, so /review-diff the retry logic in sync.ts adds a focus to a single run.

Pick a name other than code-review. Claude Code ships a bundled /code-review skill, and a project skill with the same name replaces it. Our guide to the Claude Code review skill covers what the bundled one does.

Commit the file and everyone working in the repository gets the same command. A copy in ~/.claude/skills/ is yours alone and applies to every project on your machine; when both exist, the personal one wins.

How to run a code review prompt in Codex CLI

The quickest route is built in. Type /review in the Codex CLI, choose Custom review instructions, and paste a prompt from this page without the diff block, adding a line that says what to review, such as “the changes on this branch against main.” Codex reports findings without modifying your working tree. The Codex code review guide covers the other review presets and the GitHub integration.

For a prompt you run often, make it a skill. Codex reads skills from .agents/skills in every directory from where you work up to the repository root, and from $HOME/.agents/skills for your own. A skill’s SKILL.md needs a name and a description; call it by typing $ and its name, or pick it from /skills.

---
name: review-diff
description: Review the current branch against main for bugs and security issues. Use when asked to review a change, a branch or a pull request.
---

1. Run `git diff main...HEAD` and read the result.
2. Review only the changed lines. Report problems this change introduces: bugs, security holes, data loss, crashes, performance regressions. Skip style a linter would catch.
3. For each finding give severity (Critical, High, Medium, Low), file and line, the problem, the evidence, and the smallest fix.
4. If nothing qualifies, reply "No findings."

Older setups keep prompts in ~/.codex/prompts/ and run them as /prompts:name. OpenAI now marks custom prompts as deprecated in favor of skills, and because they live in your home directory they aren’t shared through the repository.

How to use a code review prompt in ChatGPT or Claude

Without an agent, produce the diff yourself and paste it under the prompt:

git diff main...HEAD > review.diff

The three dots matter. git diff main...HEAD shows what your branch changed since it left main, which is what a pull request contains. With two dots, anything merged into main since you branched appears as if you had reverted it, and the model reviews changes you never made.

Paste the file’s contents into the block, or attach it. A chat window sees only what you give it, so when a finding depends on code outside the diff, such as the function a changed line calls, paste that too, or tell the model to say what it would need to see instead of guessing.

What makes an AI code review prompt work

Every prompt above repeats five choices. They’re what separate a review from a list of opinions.

Scope. Limit the review to the changed lines and to problems the change introduces. Otherwise the model reports old debt in surrounding code, and the real finding gets lost among them.

Severity levels. Critical, High, Medium and Low let you read the top of the list and stop. They also make the model weigh each finding before writing it.

Evidence and line references. A finding tied to a file, a line and the triggering input can be checked in a minute. One that can’t be tied to code is usually a guess.

No style nits. Formatting, import order and naming conventions belong to the linter and formatter that already run in CI, where they’re enforced every time.

A “No findings” answer. A model asked to find problems tends to find some. Naming the clean answer gives it permission to stop.

The biggest source of noise in AI code review is a prompt with no bar for what counts as a finding. Asking for a severity, a file and line, and the code that proves each problem, and accepting “No findings” for a clean diff, turns a review prompt from a request for opinions into a request for evidence that a reviewer can verify.

When to move a review prompt into rules and an automatic reviewer

Move a prompt into repository files and an automatic reviewer once the same rules apply to every pull request. A prompt runs when someone remembers to run it, and it carries what you put in it this time. Your team’s actual rules, such as “every query is scoped to the workspace” or “generated files are off limits,” get retyped, trimmed or forgotten from one review to the next.

Move the rules that hold on every change into files the repository keeps. AGENTS.md holds the conventions your coding agents follow, and a REVIEW.md holds guidance that matters only in review:

# Review guidance

## Always check
- Every API handler scopes queries to the caller's workspace.
- Money is stored as integer cents.

## Leave alone
- Formatting and import order (the formatter runs in CI).
- Generated files under src/gen/.

## Severity
- A missing workspace scope is always Critical.

With those files in place, the prompt shrinks to the part that changes per run, and the rules apply to every review, not only the ones someone started by hand. HeyDeer reads REVIEW.md and AGENTS.md, along with repository checks that each get a reviewer of their own.

An always-on reviewer removes the step of remembering. HeyDeer is an AI code review agent for GitHub pull requests: with automatic reviews turned on, HeyDeer reviews every pull request against the whole repository, verifies each finding against the code before posting it, and labels it Critical, High, Medium or Low, so the qualities a good prompt asks for are applied on every pull request without anyone pasting a diff.

Keep the prompts on this page for the moments before a pull request exists: a branch before you push, a focused security pass on one risky change, or a second opinion on code an agent just wrote. To compare always-on reviewers, see the best AI code review tools.

How to evaluate AI code review on your own pull requests

Wendy — Tue, 10 Nov 2026 12:06:55 +0000

Choose an AI code reviewer by running it on changes your team understands. Record which findings deserve a fix, which claims are wrong, and how much time the team spends checking them. A comment count alone cannot tell you whether a reviewer helped.

Download the evaluation worksheet (CSV)

1. Pick changes that represent your work

Start with a small set of recent pull requests: a routine feature, a bug fix, a refactor, and a change to a sensitive path such as authorization or billing. Include changes that your team believes are correct. Those help reveal unsupported warnings.

Ten PRs can be a manageable starting point for a pilot. It is not enough to establish a universal accuracy ranking. Expand the sample before making claims beyond your own team’s experience.

For every PR, save the base and head commit hashes. If you compare tools, give them the same revision. A review of the original change and a review after fixes answer different questions.

2. Record the context and settings

Keep the repository instructions, review depth, included files, and available context alongside the results. Record the date and product configuration too. If one reviewer receives an explanation of an important business rule, give the other reviewer equivalent information where its configuration allows it. Document any difference you cannot remove.

Evaluate the workflow you would use after the trial. If your normal process includes a follow-up review after a fix, include that run in the time and cost records.

3. Judge each claim against the code

Have a developer familiar with the change classify each distinct finding. When a claim is disputed, record the evidence and ask another developer to check it.

How to classify review findings

A comment that the team ignores is not automatically false. It may be correct but low priority, already known, or hard to understand. Keep those reasons separate so that the configuration change addresses the actual problem.

Count repeated descriptions of one bug as one distinct issue. Retain the duplicate count separately to measure how much extra reading the reviewer creates.

4. Measure the time needed to use the feedback

For each PR, record the tool’s elapsed review time, the developer’s time checking findings, and the actual charge. Keep code-fixing time separate: fixing a useful discovery is different from spending ten minutes disproving a warning.

Open the CSV worksheet in your spreadsheet app. Use one row per tool and review run; keep follow-up runs on separate rows. Record costs in the same currency when comparing tools.

5. Score the results

Precision is the share of assessed findings judged correct: valid findings divided by valid findings plus false positives. Report the counts for each classification first, then calculate it per tool from the same set of pull requests.

Precision

(valid and actionable + valid, deferred) ÷ (valid + false positives)

Define which findings enter the denominator before you start counting. Duplicates and unresolved findings stay out of it, but keep both counts visible next to the result: duplicates measure extra reading, and a large unresolved count means the score rests on fewer claims than the reviewer made. If a reviewer reports nothing, precision is undefined rather than 100%.

For example, a reviewer with 12 valid findings and 3 false positives across the trial scores 12 ÷ 15 = 80%. A second reviewer with 4 valid findings and no false positives scores 100% on far fewer useful findings, so read precision together with the valid count and the triage time from step 4.

Recall, the share of real defects a reviewer finds, needs a known set of defects. Reviewing your ordinary PRs does not establish that every bug has been found. You can add a separate exercise using known historical defects, but label those results separately and withhold the later fix from the reviewer.

6. Compare seat fees and usage-based pricing

No seat fees means adding a developer does not add a per-person charge. A product can still have a subscription, usage charges, or both. Compare the total bill for the same workload, including follow-up reviews after a new push.

Shared credits can suit a team with many occasional contributors. A seat-based plan may cost less for a smaller team running frequent reviews, depending on its limits. Neither model is always cheaper. For example, 100 PRs with two review runs each means budgeting for 200 runs, not 100. This is an illustrative workload.

Use the actual charges in your trial worksheet to estimate a normal month and a busier month. Compare recurring prices over the same billing period, separate introductory discounts from renewal prices, and check whether tax is included. Keep developer time saved separate from the amount you pay for the tool.

7. Choose a rollout threshold before expanding

Decide what would make the trial useful for your team. That might be finding previously missed issues in a critical path while keeping triage time acceptable. A threshold should reflect your repository and reviewers, not a number borrowed from another company’s benchmark.

Start with manual reviews on one repository. Use the same worksheet to check whether a change to instructions or feedback scope improves the results. Once the team trusts the feedback, expand automatic reviews gradually.

How HeyDeer fits

HeyDeer reviews GitHub pull requests with a workspace plan and shared credits. Every plan includes unlimited developers and repositories, with no per-developer seat fees. Charges depend on the review work performed.

Each private repository review, including the first, uses credits for the work performed, even when it finds no issues. Reviewing another push or running another review on the same PR uses more credits. Free includes 1,000 credits in the first month from workspace creation, then 300 each month. Public repository reviews are free within fair-use limits. Monthly credits expire at the next refresh; add-on credits are valid for 12 months. Additional credits are purchased automatically only when a workspace admin turns on auto-reload.

The cost calculator estimates the number of review runs with a few repository checks. Count each new push and repeated review separately; more checks can increase usage.

Check the current plans and cost calculator, credit rules, and spending controls against your observed workload before choosing a plan. The rollout guide covers manual and automatic review settings, and reducing noise maps common problems to specific adjustments. Our internal evaluation shows how we scored reviewer contributions during development.

The Best Free Teleprompter App Is the One That Does Less

Wendy — Sat, 13 Jun 2026 10:18:00 +0000

I’ve been recording videos for three years. And for three years, I kept downloading teleprompter apps, trying them for a week, then deleting them.

Not because they were bad. Because they were too much.

Filters. Overlays. Cloud sync. Built-in editing. Social sharing. Subscription upsells. Every new version added something I didn’t ask for and quietly removed the thing I actually needed: a clean, readable, fast-scrolling script that sat close enough to my camera lens that I looked like I was talking, not reading.

I’m a content creator. I record on my iPhone and my Mac. I don’t need a teleprompter that’s also trying to be Final Cut Pro. I need something that opens fast, loads my script, and gets out of my way.

So eventually I stopped downloading and started building. Teleprompter — Scrolling Scripts came out of that frustration. It’s the app I wanted to exist. Minimal, native, offline, free to download — and designed so that the words sit close enough to your camera that your eyes actually look natural on screen.

This is what I learned building it, and what I think most people get wrong when they’re searching for the best free teleprompter app.

The feature arms race quietly broke every teleprompter app

At some point, teleprompter apps started competing with each other on feature count instead of core performance. I get why that happens — more features means more App Store screenshots, more marketing bullets, more reasons for a reviewer to give you five stars.

But scroll performance, text positioning, and script loading speed aren’t features you can bullet-point. They’re felt. And they’re the things that got quietly deprioritized while everyone was busy adding cloud libraries and in-app teleprompter glasses accessories and AI script generators.

The result: most free teleprompter apps today are technically impressive and practically frustrating. You open them, your script is buried three menus deep, the scroll stutters at anything above 250 words per minute, and the text sits so far below center that your eyes drift downward every time you read. On camera, that drift reads as uncertainty or disinterest. Your viewers feel it even if they can’t name it.

The irony is that what makes a teleprompter work well is almost embarrassingly simple: the text needs to be close to your lens, the scroll needs to be smooth, and nothing else should require your attention.

Why “free” doesn’t have to mean watermarked, account-gated, or crippled

Here’s a real tradeoff I thought hard about: how do you offer a genuinely free teleprompter without making the free tier feel like a punishment?

The standard playbook is to gate the useful stuff. Watermark your recordings. Cap scripts at 300 words. Force account creation before you can type a single sentence. I’ve seen every variation of this. It works for conversion metrics and it’s quietly corrosive to trust.

With Teleprompter — Scrolling Scripts, I made a different call. Free means free. No watermark on your videos. No account required. No network connection required — your scripts never leave your device, which matters more than most people realize when you’re working on something you haven’t published yet.

The app runs natively on iOS and macOS. That means it uses your actual camera — the same one your other apps use — without browser permissions dialogs, without WebRTC lag, without the frame rate compromises you get from a web-based teleprompter running inside Safari. Native isn’t a buzzword here. It’s the difference between a scroll that feels mechanical and one that feels invisible.

If something is worth doing, it should work properly in its free version. That was the constraint I designed around.

The one thing that actually makes you look natural on camera

I want to be specific about this because it took me longer to figure out than it should have.

Eye contact is the whole game in video. Viewers don’t consciously analyze whether you’re reading or not — they just feel whether you’re present. And the single biggest factor in whether you look present is where your eyes are pointing relative to the lens.

Most teleprompter setups — including most apps — position the script text in the center or bottom third of the screen. That puts your gaze about six to twelve inches below your camera. On a laptop or an iPad propped up at desk height, that’s enough to make you visibly look down. You look distracted. You look like you’re reading. You look less credible.

The fix is positioning the text as close to the camera lens as possible. On an iPhone, that means the script should ride near the top of the screen, right beneath the front-facing camera. On a Mac, it means you should be able to move the text zone up toward the menu bar, not locked to wherever the app defaults.

Teleprompter — Scrolling Scripts lets you set exactly where the text lives on screen. It sounds like a small customization option. It’s actually the core feature. Everything else — scroll speed, font size, background color, text color — those help. But text position relative to lens is what separates a video where you look like you’re reading from one where you look like you’re talking.

How to actually pick the right free teleprompter app (a real framework, not a list)

I’ve tested a lot of these. Here’s the honest filter I’d apply if I were starting from scratch today.

First, does it run natively on the platform you actually record on? If you shoot on iPhone and your teleprompter is a website, you’re working around the browser every time you need camera access. That friction is real and it compounds over dozens of recording sessions.

Second, can you position the text close to your lens? If the app locks text to center screen with no adjustment, your eye contact will suffer regardless of how polished the rest of the UI is.

Third, does the free version let you do real work? If every script you write gets capped at 200 words, or every video gets a watermark burned in, you’re not using a free app — you’re using a trial that bills itself as free.

Fourth — and this one gets overlooked — does the scroll feel smooth at your actual reading speed? Scroll jitter is something you feel before you can name it. Record a test video, play it back, and watch your eyes. If they scan in little jumps instead of tracking smoothly, the scroll engine isn’t keeping up. That choppiness registers as uncertainty to anyone watching.

Teleprompter — Scrolling Scripts was built against exactly these four criteria. Not because I had a framework at the start, but because I violated all four of them at some point and had to fix my way back to each one.

If you’re recording video and you’re tired of apps that promise simplicity and deliver complexity, download Teleprompter -Scrolling Scripts free — no account, no watermark, no catch — and record one video with the text positioned right under your lens. Then watch the playback and notice what’s different.

I Tested Every Free Teleprompter App So You Don't Have To

Wendy — Fri, 12 Jun 2026 14:09:06 +0000

I spent a weekend downloading every free teleprompter app I could find on the App Store. Twelve apps. One script. One goal: read it on camera without looking like I'm reading it.

Here's the honest summary: most of them are not free. Not really.

Some hit you with a watermark burned into the corner of every recorded clip. Some require an account before you can even type a word. A few are web-based wrappers that lag half a second behind your scroll speed — which, if you've ever tried to match your speaking pace to a stuttering prompt, you know is worse than no teleprompter at all. One app I tested made me sit through an unskippable ad mid-scroll. Mid-scroll.

I've been building Teleprompter — Scrolling Scripts for three years. I know this space better than I want to. And I went through this exercise not to trash competitors, but because I genuinely wanted to understand what people are putting up with before they find something that actually works. What I found surprised me — and a few things embarrassed me into rethinking some of my own early decisions.

This is what I learned.

The Watermark Problem Is Worse Than You Think

Watermarks aren't just ugly — they're a trust signal in the wrong direction. When a viewer sees a branded watermark on your video, the message isn't "this creator uses a teleprompter." The message is "this creator couldn't afford to remove a watermark." I tested four apps that default to a visible watermark on free tier. Two of them put it dead center at the bottom of the frame, exactly where captions go. You can't crop it out without cropping your chin off.

One app I tested charges $9.99/month to remove it. For a watermark. On footage you shot on your own phone. I understand the business model — I really do — but there's a version of "free" that costs your credibility every single time you post.

The Account Wall Is a Script Privacy Problem

Four of the twelve apps I tested required email registration before I could do anything. One connected to a cloud sync by default, no opt-out visible on first launch. I had to go three levels into settings to turn it off. For a journalist, a lawyer, a founder rehearsing an earnings call — this matters more than most app reviews acknowledge.

Offline-first isn't a feature you list in a bullet point. It's a promise about who owns your words. When I built Teleprompter — Scrolling Scripts to run fully offline with zero account requirement, that wasn't a technical flex. It was a position: your script doesn't leave your device unless you decide it does. Nobody's indexing your talking points.

Browser-Based Teleprompters Have a Physics Problem

Three of the apps I tested are essentially responsive websites pinned to your home screen. They look native. They are not. The difference shows up in two places: camera access and scroll performance. Web-based apps can't call your native camera directly — they route through a browser permission layer, which means lower resolution, slower autofocus, and no access to features like ProRes or Action mode on newer iPhones.

Scroll performance is subtler but more damaging to your actual delivery. A native app can sync scroll speed to your reading pace with frame-level precision. A browser wrapper running in a WKWebView is fighting the JavaScript event loop while also trying to display your face. I timed the lag on three web-based apps. The worst was 340 milliseconds behind a tap input. That's not a rounding error — that's you rushing your words or pausing awkwardly because your eyes are waiting for text that hasn't arrived yet.

What "Free" Should Actually Mean

After the weekend of testing, I landed on a simple definition: a free teleprompter app should let you write a script, read it on camera, and export the footage — with no watermark, no account, no upsell blocking the core loop. That's it. That's the bar.

I'm not claiming Teleprompter — Scrolling Scripts is perfect. Early versions had a text positioning system that was too rigid — you couldn't move the prompt close enough to the lens on certain iPad orientations, which defeated the whole point. I shipped a fix in version 2.2 and it's one of the things I'm most proud of, because getting your eyes close to the camera center is the entire reason the "not reading from a script" illusion works. The text placement is now fully adjustable. So is scroll speed, font size, and background color. None of it requires an account. None of it phones home.

If you've been putting up with watermarks or browser lag because you assumed that's just the price of free, it isn't.

Download Teleprompter — Scrolling Scripts free on the App Store — no account, no watermark, no catch — and record your next video like you've never needed a script at all.