Skip to main content

BorderlineData

HOW IT WORKS

It's so easy.

Fast

User-friendly

Accurate

No account. No onboarding email sequence. No 34-step wizard. No lengthy legal text to click through. You pick a data type, then BorderlineData generates a comprehensive matrix of boundary values and edge data. You download them into your test cases or automation scripts. That’s it. Seriously simple.

STEP-BY-STEP

From zero to edge test data in 4 easy steps

STEP

1

Open the Toolbox

Click Toolbox in the top navigation bar. The tool loads instantly. There is no login screen. There is no “create your account” form. There is no captcha asking you to identify traffic lights. You’re welcome.

STEP

2

Choose Your Data Type

Scroll down the page to select the type of field you’re testing. There are many options, from the obvious (Email, Phone, Dates) to the delightfully niche (SWIFT/BIC codes, ISBN barcodes, Vehicle License Plates by country). If you’re testing a custom numeric range, choose Custom Range and enter your own minimum and maximum values, and BorderlineData will generate the boundaries automatically.

STEP

3

Read the Matrix

The tool instantly renders your Edge Test Case Matrix in three sections,  organised by category. Each section shows the test value, a short label explaining why it’s an edge case, and a copy button. No reloading. No waiting. No spinner with a cheeky “almost there!” message.

Example output – email addresses

Valid
user@example.com
user+tag@example.com
a@b.co
Boundary
user@localhost
user@[127.0.0.1]
a@b.c
Invalid
user@@example.com
@example.com
plainaddress
STEP

4

Copy and Use

You’ve got options, and we respect that about you:

  • Copy a single value  — click the icon on any row for an instant copy to clipboard. A satisfying green “Copied!” tooltip confirms the deed.
  • Copy an entire column — click Copy All at the top of any segment to grab all Valid, Boundary, or Invalid values at once as a newline-separated list. Perfect for pasting into a test spreadsheet.
  • Export everything — in the section “Download test Data As” you have many choices on how to download the test data, from the basic text and CSV formats, to formats compatable with popular automation testing tools and framework, such as Playwright, Cypress, PyTest, TestNG and Tosca. This makes it easy for you to import into test management tools, CI pipelines, or emailing to developers when you want them to feel things.

UNDERSTANDING THE OUTPUT

Anatomy of Edge Case Matrix

Three columns. One purpose: finding bugs before your users do. Here’s what each one means and why you need all three.

Valid Inputs

The happy-path data. These are values your system should accept without complaint. They represent the “working as intended” scenario that developers test and your system handles… until someone sends a 64-character local part in an email address.

  • Standard, well-formed examples
  • Covers common real-world formats
  • Use these to confirm basic acceptance behaviour
  • Your app probably handles these. Maybe?
Boundary Values

The interesting ones. These sit at the exact edges of what’s defined… minimum, maximum, and one step either side. All based on Boundary Value Analysis (BVA), a core ISTQB technique. This is where most bugs quietly hide, drinking your system’s coffee and waiting.

  • Min, Min-1, Min+1, Max, Max-1, Max+1
  • System limits (INT_MAX, bcrypt 72-char limit, etc.)
  • Specification edge points (leap years, Y2K38, epoch);The most important column. Don’t skip
Invalid Inputs

The chaos column. Wrong types, malformed data, injection strings, nulls, and inputs that would make a database cry. These verify that your system rejects gracefully rather than silently breaking, leaking data, or just accepting everything and storing it raw.

  • SQL injection & XSS test strings (OWASP-informed)
  • Type mismatches (text in numeric fields)
  • Empty, null, and whitespace-only values
  • Overflow, underflow, and “what were you thinking” inputs
Value Tags

Every test value comes with a short label explaining why it’s significant with things like [Overflow], [SQLi], [Luhn fail], or [Non-leap year]. These help you write meaningful test case descriptions without Googling “why is INT_MAX 2147483647 again.”

  • Explains the risk or rationale at a glance
  • Paste directly into test case description fields
  • Helps onboard junior testers without a lecture
  • Reduces the “why is this a test case?” questions by 80%*

*Statistic generated by BorderlineData’s internal “we made this up” department.

DATA TYPE REFERENCE

All the borderline and edge cases you forgot.​

Here’s what each data type covers. Hover to admire. Click Tool in the navigation bar to use.

Names / Text Strings

UTF-8 stress chars, emojis, injections, max-length strings

Phone Numbers

International formats, missing country codes, overflow

Dates

Leap years, Y2K38 boundary, Unix epoch, invalid formats

Currency / Financial

Fraction of cents, locale formats, negative prices

Numeric Integers

INT_MAX, INT_MIN, INT64, UINT32, NaN, Infinity

Email Address

Plus-tagging, double @, RFC edge cases, max length

File Upload

Path traversal, dangerous extensions, reserved names

Passwords

bcrypt limit, weak patterns, null bytes, emoji passwords

Zip / Postal Codes

US, UK, Canada, Germany, Australia, Japan, France, Singapore

Age

Newborns, centenarians, negatives, decimals, overflow

Credit Card Numbers

Luhn check, VISA, MC, AMEX, Discover test numbers, bad digits

Time

Midnight, 24:00, leap seconds, AM/PM edge cases

ISBN / Barcodes

ISBN-10, ISBN-13, EAN-13, bad check digits

SWIFT / BIC Codes

8- and 11-char bank identifiers, invalid formats

Vehicle License Plates

USA, UK, Singapore, Canada, Australia, France, Germany, New Zealand

Custom Range

Enter your own Min/Max and get boundaries automatically

USE CASES

Who uses BorderlineData?

People who’ve been manually creating test data via spreadsheets and forms, deserve better.

QA ENGINEERS & TEST ANALYSTS
Writing test cases that actually cover the edges

Use Borderlinedata to generate BVA test cases for any input field systematically. No more “I’ll add edge cases later” that never happens. The matrix is right there. Sprint review is tomorrow.

SDET & TEST AUTOMATION ENGINEERS
Seeding test scripts with structured test data

Export to JSON or CSV and feed directly into your test framework’s data provider. Parameterised tests across all three categories: valid, boundary, and invalid. And do it in two clicks. Your test coverage metrics are about to look very impressive.

DEVELOPERS
Testing your own validation logic before QA does

Stop waiting for QA to find the bug where your date picker accepts February 30th. Run your own boundary checks first. You can quietly fix it and nobody has to know. We won’t tell.

TEST LEADS & MANAGERS
Running BVA workshops and training sessions

Use BorderlineData live in training to demonstrate boundary value analysis and equivalence partitioning in real time. Probably far more engaging than a PowerPoint with clip art from 2003.

CYBERSECURITY TESTERS
Quick injection test cases without a fuzzing tool

The invalid/destructive column includes OWASP-informed SQL injection, XSS, path traversal, and null byte strings. Not a substitute for dedicated security testing, but an excellent first-pass sanity check for your input validation.

ISTQB STUDENTS & EXAM CANDIDATES
Practising Boundary Value Analysis the hands-on way

Boundary value analysis and equivalence partitioning sound abstract until you see them applied to real fields. BorderlineData makes the theory tangible. And free. Your exam prep budget thanks us.

FAQS

Questions we actually get asked

And a few we’ve pre-empted because we know you were thinking of them.

Does anything get sent to a server when I use the tool?

Absolutely not. Every test value is generated in your browser using pre-baked JavaScript data. Nothing is transmitted anywhere. No analytics on what you typed, no server logs, no “we anonymise your data” fine print. The only thing that touches a server is loading the page itself. After that, you’re fully offline-capable.

You can use them as a <em>first-pass input validation check</em> — run them through your own application’s forms to verify that inputs are being sanitised and rejected correctly. They are <strong>not</strong> a substitute for a dedicated penetration test or a proper fuzzing tool. And please, only test systems you own or have explicit written authorisation to test. We like our users law-abiding.

Boundary values sit at the edges of valid input ranges. They’re structurally correct but extreme (e.g. the maximum allowed string length, or exactly INT_MAX). Invalid inputs are structurally wrong, wrong type, injections, empty strings, or values that should never be accepted under any circumstances. Both need testing. Systems fail in different ways across categories.

After the first page load, yes. All the logic is in your browser. If you lose internet mid-session, the tool keeps working. The Google Fonts may fall back to system fonts, which is fine. The test data generation itself has zero dependency on network connectivity. Useful for when you’re testing in an environment without internet and really need to know what happens with a 255-character password.

Because good test tooling should be accessible to everyone — not just teams with budget approval and a procurement process that takes six weeks. Also, building a payment system would introduce approximately fourteen new edge cases that we’d have to test ourselves, and that felt a bit too on-the-nose. We’re supported by the ads on the page. If you’d like to support us further, share the tool with others. It costs nothing and makes them unreasonably happy. And us too.