A Practical Guide to Preparing Web Content for Your Developer

A message from a developer (and designer) to content managers, marketing teams, and point people: help us help you.

Your team has decided on a redesign or a new website, you’ve hired a developer or an agency to perform the work and it’s full steam ahead. Great!

Here are a few tips from a developer and designer on how to provide content in a way that makes our jobs easier. And it will help you get organized as well. That seems like a win-win to me.

Tip #1: One space after a period. Period.

If you were taught two spaces after a period in school, that doesn’t apply to digital text — that is a holdover from the ye olde days of mechanical typewriters. Use only one space after a period otherwise we have to go in and fix it. Everywhere. For a multi-page site, this can waste valuable development time.

Tip #2: Use proper dashes:

em dash (Shift-Option-Dash): for setting off words or clauses — like this one — in a sentence. Some word processing programs will convert a double dash/double hyphen -- into an em dash but it’s better to actually use the real thing where appropriate.

en dash (Option-Dash): for sequences e.g. 4–8 months. Notice this dash is slightly longer than a hyphen.

hyphen/dash: for hyphenated words like short-term plan or old-fashioned typewriter.

Tip #3: Use Spell Check.

As developers, we are often the last line of defense before your content is published to the world. We don’t want you to look bad so if we see errors in your text — including spelling errors — we will fix them.

Still, it’s not that hard to use the spell check tools in your applications and save us this step.

Tip #4: Keep things consistent.

If you have a section labeled ‘The Challenge’ in one place, then ‘Our Challenge’ somewhere else, then ‘Challenges’ in another place and they are all referring to the same thing, then either we have to decide which one to use or contact you to clarify. If you can, make this decision and apply your choice(s) before sending your content to us.

Consistency also applies to text. If you have bulleted lists, either add a period at the end of each bullet point or don’t — it’s really up to you. But don’t do both. It may seem like a little thing but fixing all of these takes valuable time.

Tip #5: Don’t embed everything in a Word doc.

Developers are pretty used to getting content in all kinds of ways and formats: text via email, Dropbox, PDFs, spreadsheets, PowerPoint files — you name it, we’ve seen it.

Yet, the worst way to receive content is a pre-formatted Word document with all of the images and links embedded in the file. There’s nothing wrong with Word documents per se but if you are going to use Word, don’t add more than basic formatting (bold, italic, etc.), send the images separately, and include footnotes to links instead of embedding urls into the text. Or at least include full url links after the linked text.

If you pre-format your document to make it look like you want, that only creates more work for the developer as we have to strip out all of the styles and formatting you’ve added, only to add it again with HTML.

Leave your files as plain as possible and your developer will thank you.

Tip #6: Provide original, full-resolution images.

We do a lot of image manipulation to prepare content for the web: resizing, cropping, rotating, color correcting, and more.

Let us handle this the right way by providing us with original, full-resolution images so we can make them look good on every device.

Tip #7: Provide logos in vector format.

We’ll need to resize your logo (or any other logo) so give it to us in a vector format so it will look crisp everywhere.

Vector graphics formats include:

  • Adobe Illustrator (.ai)
  • EPS (Encapsulated Post Script) (.eps)
  • Adobe Photoshop (.psd)
  • Editable PDF (.pdf)
  • Sketch (.sketch)
  • Scalable Vector Graphics (.svg)

Your designer should have your logo in one of these formats and you should have a copy of it.

Note that JPEG (.jpeg), PNG (.png), and GIF (.gif) are not vector formats and don’t retain their resolution when scaled.

Tip #8: Gather all your logins.

Invariably when starting a new project, your developer will need some or all of the following logins:

  • hosting
  • current site admin
  • FTP
  • domain registrar
  • payment processor
  • plugins
  • portals with embeds

In my experience, clients never have these ready and often weeks can go by before all the required logins are tracked down. While this doesn’t halt work completely, it can cause bottlenecks while we’re waiting for access.

One thing my agency does at the end of every project is send over a sheet with all the logins in one place for our clients. They really like having this and can add to it moving forward.

Tip #9: Pick a point person who is responsible for the project.

As a developer, it can be aggravating dealing with multiple people or a committee, especially when no one is responsible for getting us what we need.

Before embarking on your project, pick a point person and give them the authority to get what they need while also make them responsible for the project.

For us, having one person to deal with is much easier than wading through multiple email threads or trying to get clarification or approval from multiple people.


We ❤️ our clients. Help your developer love you too by providing content to developers so that they can present your organization in the best way possible.