How to Use Cookies, Part III

Why Cookies Enhance User Experience on Forms

When a visitor lands on a page that hosts a feedback or contact form, the first thing they see is a series of blank fields. Filling them out again and again can be annoying, especially if the visitor has already shared their details with you in a previous visit. Cookies solve this problem by storing small pieces of data on the visitor’s machine, allowing those details to reappear the next time the form loads. This technique keeps the user engaged, reduces friction, and can even lower bounce rates.

The power of cookies lies in their simplicity. Unlike server‑side sessions that vanish when the browser closes, cookies can persist for days, weeks, or months, depending on the expiration you set. By writing a cookie that contains a user’s name, email address, or other common fields, the next time the form loads, a script reads the cookie and populates the fields automatically. The user sees a form that already knows their information and only needs to fill in the remaining details.

Because the information is stored locally, no extra database queries are needed when the page loads. The JavaScript reads the cookie, parses its value, and writes it straight into the form fields. This process is fast, invisible to the user, and imposes no extra load on your server.

Beyond convenience, cookie‑based autofill can also reduce spam. When a visitor’s data is stored in a cookie, the form can send a hidden field that proves the visitor has already interacted with your site. Spammers, who typically fill out forms from scratch each time, will not trigger this hidden field, making it easier to detect and filter unwanted submissions.

The example demo that accompanies this article demonstrates these concepts in action. The demo page uses a Perl CGI script that runs on a UNIX or Linux environment with Perl 5 or higher and the sendmail program. When the visitor submits the form, the script first encrypts the email address and then emails the full form data to you. At the same time, it writes the user’s data into cookies on the visitor’s hard drive. On the next visit, JavaScript reads those cookies and pre‑fills the matching fields.

While the demo is focused on a feedback form, the same code can be applied to any form that has field names matching the cookie names. If you rename the fields consistently across multiple forms - say “name”, “email”, and “phone” - the cookie data will be reused wherever those fields appear. This makes it trivial to create a network of interconnected forms that remember the same user data across your site.

Because the CGI script applies a light encryption to the email field, your inbox receives a version of the address that is a bit cloaked, protecting it from easy harvesting. This added layer of privacy shows that the cookie system is designed with security in mind, not just convenience.

Learning how to implement this approach is straightforward if you follow a few key steps: (1) make sure your server can run Perl and sendmail, (2) copy the CGI script and JavaScript into your project, (3) adjust the form field names to match the cookies, and (4) test the flow from first visit to subsequent visits. The demo page on http://willmaster.com/a/6/pl.pl?art70 lets you see the entire process from start to finish, so you can confirm that the fields pre‑fill correctly and that the email is sent securely.

Installing and Customizing the CGI‑JS Cookie Feedback Form

Getting the Demo and Understanding Its Structure

The demo that powers this tutorial is called the CGI‑JS Cookie Feedback Form. Its source files are divided into a Perl CGI script that handles the server‑side logic and a JavaScript file that runs in the visitor’s browser. The Perl script is heavily commented, so you can read through it and see exactly where the cookies are created and how the email address is cloaked. The JavaScript file, on the other hand, contains simple functions that read the cookie values and assign them to the corresponding input fields.

Before you dive in, make sure your environment satisfies the script’s prerequisites. It requires Perl version 5 or newer and access to the sendmail program for email delivery. The script is written for UNIX or Linux servers, but it can run on Windows if you install a suitable Perl distribution and an SMTP relay.

Once you confirm the environment, download the demo files. Place the CGI script in the cgi-bin directory (or wherever your server executes CGI scripts). Save the JavaScript file in a location that your HTML page can reference - common choices are the same directory or a dedicated /js folder.

Now open the demo’s main page, http://willmaster.com/a/6/pl.pl?art70. Notice how the form fields are labeled: “Name”, “E‑mail”, “Phone”, and “Comments”. Each field has a name attribute that matches the cookie name the script will set. If you plan to rename the fields in your own form, keep the cookie names consistent to allow automatic population.

Customizing the Form Fields and Layout

Customizing the form is a matter of editing the HTML file that holds the form markup. The Perl script expects the following field names: name, email, phone, and comments. The JavaScript reads these names and looks for cookies that share the same identifiers. If you change any of the names, update both the form and the CGI script’s my @fields = qw(name email phone comments) line so they stay in sync.

When you design your own layout, you can still rely on the same JavaScript by preserving the cookie logic. For example, you might wrap the fields in a <div> with a custom class or use CSS to style them. The JavaScript functions only care about the name attribute, not about the surrounding markup.