With Restrict submissions to one per IP address turned on, Responsly blocks duplicate survey responses that come from the same public IP address: it accepts the first response from each address and blocks further submissions from it. Unlike the browser-level check, it doesn’t rely on cookies, so answering again in another browser or a private window on the same connection usually doesn’t get around it, unless one of the browsers uses a VPN or iCloud Private Relay.
Use it on public survey links, polls and contests where most people answer from their own connection. Leave it off when many respondents share one network, such as an office, a school or a hotel. The other ways to prevent duplicate survey submissions, and how they compare, are in the main guide.
Turn on one response per IP address
- Open your survey.
- Go to Settings → Security.
- Turn on Restrict submissions to one per IP address.
- Save or publish as usual. Before you share the link, test it from a connection your respondents won’t share.
How the IP check works
Every device online reaches Responsly through a public IP address: the address of the internet connection it uses, not of a person. On most IPv4 connections, every phone and laptop behind a home or office router shares one public address, and in an office that can be hundreds of devices. On IPv6 connections, devices often have addresses of their own that change over time, so two people in one home or office may not share an address. The private address a device shows in its own network settings, such as 192.168.1.20, is not the one websites see.
Responsly doesn’t save the IP address itself with the response. For duplicate detection it keeps only an encrypted form of the address, along with an encrypted cookie in the respondent’s browser. With the check on:
- The first response from an address is accepted, and its encrypted form is kept.
- When another response to the survey arrives from the same address, it matches the encrypted value and the submission is blocked.
The check recognises that two submissions came from one address. It isn’t designed to identify who sent them. What a blocked respondent sees on screen is easiest to check yourself, as described in Test before you launch.
What the IP check protects against
- Reload and resubmit. A respondent submits, opens the link again and answers a second time.
- Getting past the browser check. Another browser, a private window or cleared cookies on the same connection usually still arrive from the same address.
- Stuffing a poll or contest. One person submits an online poll, vote or contest entry over and over from one device or network.
- Low-stakes public surveys. Open feedback forms and small giveaways where you’d rather not ask for an email address.
Together with the browser-level check, it raises the effort needed to answer twice. It doesn’t prove that each response comes from a different person.
Risks and limitations
One IP address can be many people
Many devices can share one public address:
- On IPv4, routers send every device on a network through one public address. Offices, schools, universities, hospitals, hotels, cafés and event venues often put dozens or hundreds of people behind it.
- Mobile carriers and some internet providers use carrier-grade NAT, which puts many subscribers behind one public IPv4 address. Cloudflare’s write-up on shared IP addresses notes that one IPv4 address can represent hundreds of users or more, so a block aimed at one of them can catch the whole group.
- VPNs and relay services route many users through shared exit addresses.
With the IP check on, once one person on a shared address submits, others on that address can be blocked from submitting. This is why it doesn’t suit QR code surveys placed in a restaurant, hotel or event venue where guests use the same Wi-Fi, or internal surveys answered from the office network.
A different connection gets past it
The check limits an address, not a person. Someone who answers again from another connection arrives with a different address: mobile data instead of Wi-Fi, another location, a VPN, or iCloud Private Relay, an iCloud+ feature that hides the real address from websites opened in Safari. Some internet providers also reassign home addresses regularly, some of them daily, so the same household can come back with a new one. On IPv6, devices can also switch to new temporary addresses on their own.
Treat the IP check as a speed bump for casual repeats. When each response must come from a different person, choose a method tied to the person rather than the network; see when to use another method.
It isn’t bot protection
Vote bots and scripts can get past per-IP limits by spreading submissions across proxy and VPN addresses. The IP check slows down one person on one connection; it isn’t a defence against organised fraud. Responsly’s separate bot protection (Cloudflare Turnstile) checks in the background that a person, not a bot, sends the response; it isn’t available on a custom domain. For high-stakes votes and valuable prizes, use invitations or a unique-value question.
Encrypted is not the same as anonymous
The IP address isn’t stored with the response: for this check, Responsly keeps only an encrypted form of it. Keep two things in mind when you describe the survey to respondents:
- The address is still used to show the survey. As on any website, the respondent’s IP address reaches Responsly when the survey opens and is used to display it (Privacy Policy, section 4). So write “we don’t store IP addresses with your answers”, not “we don’t collect IP addresses”.
- Encrypted data can still be personal data. Under the GDPR, IP addresses are online identifiers and can be personal data. An encrypted IP address still tells repeat submissions from one address apart, which is the point of the check. The EDPB guidelines on pseudonymisation (adopted 16 January 2025, version for public consultation) treat such data as personal data unless the conditions for anonymity are met.
If you promise respondents full anonymity, don’t rely on the IP check. Turn it off and use anonymous email invitations, which don’t link answers to the invitee, when you need one response per person. Under section 2 of the Privacy Policy, the customer that created the survey informs respondents about the data collected, so check the wording with your data protection officer or legal adviser, especially for employee and HR surveys.
When to use another method
The IP check fits public links answered from people’s own connections. For other situations, pick a method from the comparison of all duplicate-prevention methods, which covers the setup for each one.
| Your situation | Use | Why |
|---|---|---|
| Public poll, contest or feedback link, answered mostly from people’s own connections | Browser-level check plus the IP check | Stops most repeats from the same address, including from another browser or a private window |
| Respondents share a network: office, campus, hospital, hotel, event or venue Wi-Fi | Turn the IP check off; use the browser-level check only, or email invitations with unique links | With the IP check on, the first person to submit can block others on the same address |
| Each person must answer exactly once | Turn the IP check off and use a method tied to the person, such as invitations or a question that requires a unique value | The IP check limits an address, not a person |
Test before you launch
Your own test answers come from your network too, so plan the test:
- Send test submissions from a connection your respondents won’t use, such as your home network, not the office Wi-Fi they’ll answer from. Do this even while the check is off: responses sent before you turn it on may still count.
- Preview answers are saved in Analysis like real responses; see testing the survey. Assume they may also count toward the IP check.
- To see what a blocked respondent sees, submit once from the live link on a connection your respondents won’t share. Then open the link in another browser or a private window on the same connection and try to submit again.
- If the survey also uses email invitations or Save & Continue, test those flows with the IP check on before you send.
- Delete test responses before launch. Don’t assume that deleting a response lifts the block for that address; if it matters, try another submission from that connection, then delete it too.
If respondents say they can’t submit
Ask where they answered from. On a shared network such as an office, a school, a hotel or public Wi-Fi, or behind a VPN, someone else may already have responded from the same address. Turn off Restrict submissions to one per IP address, then:
- keep the browser-level check, or
- send email invitations so each person has their own link, or
- ask for a unique value, such as an email address or an employee ID, and block repeats on that instead.
Related: unique codes for each respondent and identification of respondents when you need to know who answered, sharing a survey link for the public link this check is meant for, and the survey distribution channels you can switch to when your audience shares a network.
